Bugzilla – Bug 639
slimserver shouldn't respawn failing converter
Last modified: 2008-12-18 11:52:57 UTC
While trying to get ogg working on the linkstation, it turned out that the command line arguments that slimserver used for oggdec would just cause it to exit and say "ERROR: No input files specified. Use -h for help" (the command-line usage changed between 1.0 and 1.0.1). The bug is that slimserver kept trying over and over again, using all the CPU spawning oggdec process after oggdec process with the same args and getting the same empty output. I'd propose that the right reaction to a conversion process that returns no output is to treat the song as played; is it really likely that the process will fail (bad arguments, dump core, etc) on one run and succeed the next time in the same environment with the same file?
vidurl, what do you think for 5.4?
Did you have repeat mode turned on for the Now Playing list? If so, it's probably the case that we're looping back to the top of the playlist after failing. The song is treated as played, but just for that iteration of the repeated playlist. I'm not sure what the correct behavior is if playback fails for a song. Is it to mark it in the database as non-playable and never try again? If so, we'd have to create a way to allow a user to explicitly re-enable attempting playback.
a playlist full of failing files should reach the end of a playlist, reset to the start and go into stop mode. This used to be the case if it isn't any more. This way there was a default resting place. The server would have to have some user interraction at that point, regardless of what the repeat setting is. If the user moved files temporarily, then back again, the playlist would work just fine by pressing play to start it over. no flag is stored, it simply skipped through bad files until there was a good one, or until the end of the playlist is reached.
I suppose it was a single song in the playlist and "repeat all" mode. KDF's suggestion is fine with me - if all songs in the playlist fail, then stop at the end whatever the repeat setting.
We did go into stop mode after a failure? When was that and how was that done? In some cases, especially ones where we use a transcoding application, we may not even be able to detect a failure.
transcoding is what is the difference here. In cases of unreadable/missing files, it skips then stops at the end. With transcoding, we should probably aim to match this behaviour. if there really is no way to detech a failed transcoding session, that could be a real problem.
We should check $? (shell exit code) for a non-zero value >> 8
Please reopen if anyone is still seeing this problem.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.