Skip to content
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

Closed
lazka opened this issue Mar 15, 2015 · 6 comments
Closed

Cyclic queue save; Restore song on start not in the song list #1358

lazka opened this issue Mar 15, 2015 · 6 comments

Comments

@lazka
Copy link
Member

lazka commented Mar 15, 2015

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?

  • Move the album selector to some album, any album. Then play a song NOT in that album. While this song is playing, quit QL. Now start QL again. The "now playing" field is now blank; QL does not recall playing any song before it quit. This behavior is not observed when the album selector is set to "All Albums."
  • Play a song, and while playing said song put it somewhere in your queue (doesn't matter where). Quit QL. Now start QL again. While the "now playing" state is correct (barring the above case, it remembers the song and how long it was playing), the first queued instance of the same song is now gone from the queue. Imagine the following:

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.

@lazka
Copy link
Member Author

lazka commented Mar 15, 2015

Comment #1 originally posted by reiter.christoph on 2014-08-27T19:00:37.000Z:

Thanks. Sorry for the delay.

  1. For queue saving; we do save the library if something changed every few minutes; we could do the same for the queue..

  2. QL can only restore the playing song if it is in the restored song list. I agree, could be improved.

  3. This was fixed in revision 5443e4d

@lazka
Copy link
Member Author

lazka commented Mar 15, 2015

Comment #2 originally posted by HiKaPh on 2014-08-28T02:46:17.000Z:

  1. To be honest this bug was my own ego (from a different email address) speaking, I doubt that many users hit this corner case with any frequency. I ended up writing my own dirty kludge to get around this by reading the output of "--print-queue" and percent-decoding before outputting to the queue file. But thanks for your consideration anyway.
  2. Aha. Well, at least the behavior is known now, in which case it's no longer really a problem.
  3. Great! Thanks very much.

@lazka
Copy link
Member Author

lazka commented Mar 15, 2015

Comment #3 originally posted by reiter.christoph on 2014-08-28T12:53:12.000Z:

  1. Fixed in revision 6245d85

@gwemmie
Copy link

gwemmie commented Jan 28, 2018

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.

@j39m
Copy link

j39m commented Feb 10, 2019

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.

@bassstorm
Copy link
Collaborator

Closing this ticket as it is partially fixed and more clean #3649 is created for the rest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants