mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
New argument parsing fails with space-containing args #378
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @joshuaboniface on GitHub (Feb 3, 2019).
I'm not sure exactly why, but when trying to use arguments in variables with spaces (#749), this fails:
Similar situation with the optional
ffmpegarguments:However, adding an
=causes it to work:Given that the other (
--*dir) options don't seem to require an=, something is fishy here. Will track testing to see if this is a systemd oddity, or an argument parsing oddity.cc @ploughpuff @Bond-009
@JustAMan commented on GitHub (Feb 3, 2019):
I think it is the issue with scripts that start jellyfin. They're probably using problematic args like
"$ENVVAR"(extra quoting).@ploughpuff commented on GitHub (Feb 3, 2019):
I can reproduce this on the command line as follows:
Can you try removing the double quotes from JELLYFIN_RESTART_OPT:
JELLYFIN_RESTART_OPT=--restartpath /usr/lib/jellyfin/restart.shor
JELLYFIN_RESTART_OPT=--restartpath "/usr/lib/jellyfin/restart.sh"@joshuaboniface commented on GitHub (Feb 3, 2019):
That's not going to work, these are BASH variables with spaces (since its a flag and value) so removing the quotes will throw syntax errors. I could work around that for the restart one, but not the ffmpeg ones since there's two there.
@ploughpuff commented on GitHub (Feb 3, 2019):
Before the invocation can you echo out the $JELLYFIN_ARGS string. I suspect there are some double-quotes in there (somehow not removed in bash var expansion?).
Also this local hack would help. In Jellyfin.Server/Programs.cs, print out the args strings:
I would expect to see something like:
--datadir
/var/lib/jellyfin
--configdir
/etc/jellyfin
--restartpath ~/blah/blah/restart.sh <-- Note how on one line..
@joshuaboniface commented on GitHub (Feb 3, 2019):
So just some more data points before I try recompiling something:
It looks like this setup "works" in the sense that it doesn't error out:
Which creates this
systemdCLI:And these are the printed arguments:
But ultimately this doesn't work, and the ffmpeg arguments are ignored. This is the case even if I only set one of them, e.g.
@ploughpuff commented on GitHub (Feb 3, 2019):
Ultimately it doesn't work because the parser cannot handle one long string, like this:
"--ffmpeg=/usr/bin/ffmpeg --ffprobe=/usr/bin/ffprobe"
Worth noting, from your final point, the --ffmpeg and --ffprobe switches must be given together or they are ignored. In that case I think the s/w searches AppPath and PATH for an installed version to use..
@ploughpuff commented on GitHub (Feb 3, 2019):
Parser is happy with:
--ffmpeg path
--ffmpeg "path"
"--ffmpeg=path"
"--ffmpeg=path" "--ffprobe=path"
Parser not happy with:
"--ffmpeg path" (Error: Option 'ffmpeg path' is unknown.)
Parses ok, but gives wrong expected result:
"--ffmpeg=path --ffprobe=path" (s/w has ffmpeg path set to "path --ffprobe=path", and ffprobe is null)
@JustAMan commented on GitHub (Feb 3, 2019):
@joshuaboniface what I suggest should work,
exportstatement in bash behaves differently about spaces iirc, and that difference is probably the root cause here.@joshuaboniface commented on GitHub (Feb 4, 2019):
This one doesn't work in bash/systemd units, the intervening space is ignored.
In my case, it defaults to what's set in the UI rather than overriding this.
I'll just specify every option explicitly in the environment with its own variable. It's a bit gross and I'd prefer the software to handle this better, but it's not a deal-breaker.
Edit: There were only two more that should ever really be used, so it wasn't too bad with this method. PR open.