dbaelde
commented
9 years ago I'm not sure to understand the issue here. Liquidsoap cannot play a deleted file... unless it has been opened (playing started) before you delete it.
Closed giflw closed 9 years ago
dbaelde
commented
9 years ago I'm not sure to understand the issue here. Liquidsoap cannot play a deleted file... unless it has been opened (playing started) before you delete it.
giflw
commented
9 years ago I have deleted and recreated it again, with same name and content. After that, reloading playlist made it play twice in a row every round. Em 11/11/2014 07:05, "David Baelde" notifications@github.com escreveu:
I'm not sure to understand the issue here. Liquidsoap cannot play a deleted file... unless it has been opened (playing started) before you delete it.
— Reply to this email directly or view it on GitHub https://github.com/savonet/liquidsoap/issues/195#issuecomment-62519776.
dbaelde
commented
9 years ago Please realize that getting into a log is time consuming, especially with very little context as is the case here. It would have helped to know at what timestamp in the log I should look for an anomaly. There are see plenty of places where Clint_Eastwood is played twice in a row.
The time where you delete some file seems to be 23:54:38. There, liquidsoap complains about two playlist entries that do not exist. It reaches the end of the list, reloads, gets an empty playlist and thus keeps the old one (twice). It keeps struggling with files that do not exist. That all seems normal.
At 23:54:42 it loads a new non-empty playlist of 1 entry, then manages to load Clint_Eastwood which you have restored. It plays it and reaches the end of the playlist. At this point it reloads the file at 23:59:17 and the playlist at 00:03:35. I wonder here why it does not reload the playlist immediately. I can investigate this more closely later.
After the reload at 00:03:35 it says it has two tracks but it plays Clint_Eastwood three times before reloading. Did you cut the log or kill liquidsoap afterwards? I would be interested to know whether it keeps going like that.
One question: is /tmp/music a normal directory? (no NFS, fuse)
giflw
commented
9 years ago Sorry for the trouble reading the log. This is the full log (as I remember), and I have tested sometimes before opening this issue, and the strange behavior persists until I reload the playlist, supposing the deleted file is not put back on the folder. For each time I delete/put back the file on the directory, it got played one more time in a raw.
Regarding to /tmp/music, I'm using Ubuntu 14.04 with default setup. I checked and /tmp seems to be a common directory on the filesystem. Inside it I created the music directory.
I tested this behavior with files and symbolic links. I also tested with playlist as file instead of directory, and in that case it worked as expected, as I remember.
dbaelde
commented
9 years ago In my previous comment I identified two oddities, and I believe they come from the same issue: in the first case, there is a single file in the playlist but it is played twice before reload; in the second case there are two files (twice the same) in the playlist but it is played three times before reload.
This is due to the fact that reloading is triggered after that the end of the playlist is played, i.e., at the time when the first item of the playlist is picked again. I have changed this locally, so that the playlist reload is programmed after that the last item is picked. However, this interacts badly with another feature: when reload is performed, it cancels the files previously loaded. (This is nice because it allows the reload to take effect immediately even though we prepare files in advance.) As a result, on the example of a single item playlist, I get the following behavior: load playlist, prepare item, reload, cancel item, prepare (same) item, ... (this can happen a number of times until) play the item.
To conclude, I agree that there is a bug in our current reload strategy for the randomize mode but I don't have a patch yet. I could try to be clever with request expirations and create a special case for this kind of scenario, but I would like to find a simpler/cleaner approach instead.
dbaelde
commented
9 years ago I've been thinking about this a bit more, and it seems to me that the right approach is simply to not use expirations when reloading after a round. Expirations make sense for manual, time- and watch-based reloading but not for round-based ones. Unless somebody contradicts me, I'll just have to figure a way to disable expirations in round-based reloaded playlists, but re-enable them selectively for manual reloads.
giflw
commented
9 years ago Can you make something to enforce reload just after the prepared item start playing? You pointed that in your atempt, this behaviour occurs: load playlist, prepare item, reload, cancel item, prepare (same) item. Is there a way to make a reload only after start playing item? Something like this: load playlist, prepare item, start playing item, reload, cancel item, prepare (same) item. Maybe using a listenner or an observer pattern?
dbaelde
commented
9 years ago The issue should be fixed now. I'll consider merging soon but would welcome feedback. Tests confirm the fix but nothing tells us that backward compatibility is preserved: we should make sure that we did not remove expirations where they were needed.
liquidsoap version: 1.1.1
Using the script below, i copy 2 songs in a folder (/tmp/music).
After deleting one file and and copying it again to the music folder, playlist reloads 2 files, but play the deleted file twice. If I delete the file and copy it again, that file is played tree times.
Same occurs if I use
randomizemode.liquidsoap log: