-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cyclic queue save; Restore song on start not in the song list #1358
Comments
Comment #1 originally posted by reiter.christoph on 2014-08-27T19:00:37.000Z: Thanks. Sorry for the delay.
|
Comment #2 originally posted by HiKaPh on 2014-08-28T02:46:17.000Z:
|
I'd actually love to see this get implemented. You might remember when I was asking for help with various things around doing the --print-queue method that HiKaPh mentioned. After upgrading to quodlibet 4, about 80% of the functionality in my wrapper script just stopped working. Some of the issues have nothing to do with quodlibet and are as if they're bugs in Bash itself, despite being caused by the upgrade. I remember when I was first making the script, I had to deal with several bugs that were just as bizarre for the same reasons, and I'm not interested in doing that again. Meanwhile, quodlibet has gotten so much more robust at everything (especially remembering the currently playing song, even if it crashes) since I first started using that script. Having a queue that saves to $HOME/.quodlibet/queue every time it changes, rather than just when the program exits, is all I need to never miss that script again. |
I wrote my own script (probably similar to yours) in Python. Long ago, it was quite useful when I was hitting strange system-wide and GStreamer (I think) bugs; today, it's not so useful any more, but I still do run it as a security blanket. |
Closing this ticket as it is partially fixed and more clean #3649 is created for the rest. |
Original issue 1358 created by kalvin.rubiksmaster on 2014-04-01T03:07:32.000Z:
As of now, the file which notes the queue contents (for me, ~/.quodlibet/queue) seems only to be written once per run: at the very end, when one exits QuodLibet.
If QuodLibet is forcibly killed for any reason (e.g. complete system crash), the queue file is not written, and the user is faced with a queue state that's really, really old when QuodLibet next starts.
For example, imagine my queue (upon start-up) is
song1
song2
song5
song6
song8
Let's say I completely empty my queue and enqueue some entirely different pieces such that the queue now looks like
song99
song88
song55
Imagine now that inexplicably and unfortunately, QuodLibet crashes without a chance to clean up or do exit writes. After some panicking (and probably rebooting), I restart QuodLibet. Gone or songs 99, 88, and 55 from the queue - instead, the initial five-song queue is back in place.
I'm not proposing anything, but just curious if this would be easy to implement (because if it is, I might have a crack at it myself): might one somehow modify the output of "quodlibet --print-queue" and redirect it to the queue file? The single difficulty is the output prepending file:/// to every item in the queue and treating special characters the funny way.
This to me would be more user-friendly than quitting and restarting QuodLibet every time I want to see my queue written (just in case. Bad things do happen every now and then on my personal system).
There are some miscellaneous queue idiosyncrasies I'd like to note; these are probably less bugs and more oddities not completely covered in the documentation?
now playing: song5
queue: song1, song2, song3, song4, song5, song6, song7, song5, song5, song5
/* Quit. Restart. */
now playing: song5
queue: song1, song2, song3, song4, song6, song7, song5, song5, song5
Just a little curious.
The text was updated successfully, but these errors were encountered: