Repository navigation
DSF/DFF playback intermittently fails with “Couldn’t create command line” after player reconnect (usedop=1, DoP) #13
Description
Environment
- Lyrion Music Server 9.1.2-stable (ghcr.io/lms-community/lyrionmusicserver:9.1.2-stable), Docker on Unraid
- DSDPlayer plugin 1.14
- Player: Osmium Sound (squeezelite 2.0.0-1517), MAC xx.xx.xx.xx.xx.xx
- Squeezelite command in DoP mode: squeezelite -m xx.xx.xx.xx.xx.xx -o hw:CARD=AUDIO,DEV=0 -D -v -C 5 -s 192.168.1.2 -n Osmium-01 -M Osmium -r 384000 -b 16384:8192
- Per-player prefs (playdsd.prefs): usedop: 1, resample: '::::::', gain: 0
- No custom-convert.conf rules (restored to the original flac-only file)
Problem
DSF and DFF files play correctly in DoP at 5645 kHz on the DAC, but the failure is intermittent. After some player reconnections, both formats fail with:
Slim::Player::Song::open (426) Error: Couldn't create command line for dsf playback for [file:///music/...2L-109_stereo_5644k-1b_05.dsf]
Slim::Player::Song::open (426) Error: Couldn't create command line for dff playback for [file:///music/...2L-082_stereo-DSD_01.dff]
The TranscodingHelper debug log shows that no dsf-flc-- or dff-flc-- command is found; the only candidate is dsf-mp3-*-, which fails because ffmpeg is not in the container.
Observed sequence
- LMS restarted: DoP playback works.
- Osmium restarted: both formats fail (repeatedly).
- LMS restarted: works again.
- Osmium restarted: works.
So the failure is not tied to a specific restart. It looks like the per-MAC transcoder rules are sometimes not registered when the player reconnects (the plugin registers them on client new/reconnect in setupTranscoder). I have not been able to confirm the root cause. The plugin does not log anything in setupTranscoder, so there is no direct evidence of when registration happens.
Question
Is there a known race between the client new/reconnect event and the registration of the dsf/dff/wvpx transcoder entries? Is there a way to log registration to confirm it?
Activity
gfcodo commentedon Nov 7, 2026
Update with new observations.
DoP (usedop=1, File DSD = DoP, squeezelite with "-D -v"): DSF/DFF playback fails intermittently with "Couldn't create command line". Restarting LMS sometimes restores it, sometimes not. Restarting the player (Osmium) alone is not reliable either.
With usedop=0 (PCM branch of dsdplay), the DSF fails with the same error. So the failure does not depend on the -u (DoP) command; the per-MAC dsf/dff entries seem not to be registered.
SqueezeDSP is enabled on the same player. Disabling it did not change the result. In the log, the only lookups for dsf on this player are "dsf-mp3-*-" via "[ffmpeg] ... | [SqueezeDSP] ... --formatout=MP3", and ffmpeg is not installed in the container.
Working configuration: File DSD = Automatic (squeezelite "-D :u32be", native DSD). DSF DSD64 and DSF DSD128 both play, with no LMS restart needed after a player restart. So native DSD bypasses the DSDPlayer path entirely.
Environment: Lyrion Music Server 9.1.2-stable (ghcr.io/lms-community/lyrionmusicserver:9.1.2-stable), DSDPlayer 1.14, player Osmium 2.0.0-1517 (squeezelite), Docker on Unraid.
Happy to run any diagnostic you need on the server side. Thanks.
gfcodo commentedon Nov 9, 2026
Update: the Osmium maintainer has replied with an explanation of the boot-time behaviour on their side.
According to them, Osmium regenerates the squeezelite configuration at every boot from the UI settings. If a track tries to resume playback during that window, LMS can report "Couldn't create command line". They confirmed that "-D" without a format is the expected DoP configuration on their system, and they plan to fix the race in a later release.
This matches part of what we observed: the failures appear after Osmium restarts, and LMS restarts often restore playback. However, the lookups in the log still never show a dsf-flc-- or dff-flc-- entry, and the failure also happens with usedop=0, so I cannot yet tell whether the per-MAC rules are missing because the player reconnects during the race, or because the plugin does not register them on that reconnect event.
Workaround under test: disabling "Ripristino all'accensione" (resume on power-on) for the player in LMS, to avoid resuming during the boot window. I will report the result.
Question: on a "reconnect" event, is there any condition under which setupTranscoder() is skipped, for example if the player's preferences or capabilities are not ready yet? If it would help, I can test with a DEBUG log of the plugin.