Queue is messed up with 537. I use a simple system 1 zone for main stereo. I normally add tracks to queue as music plays so I have upcoming music in the queue. With earlier versions when a song finished playing it moved to history and the next song (now playing) would be at the top of the queue. With 537 when a song finishes playing it moves to history but now that song is visible at the top of the screen and the dialog box appears with “jump to whats playing” if I do nothing as more songs finish the visible history gets longer and longer. Last night it moved back 1 full day and my upcoming queue tracks were no longer visible unless I hit the “jump to whats playing” dialog. I have been a roon user since 2015 this issue is new, no changes to system other than 537. I had no other issues other than this annoying new trait.
Based on the way I select tracks and use roon this will become really annoying, even more so than when you removed the favorite heart from the task bar, and radio will begin playing in XX.xx mins from the radio side.
Not sure if it is the same issue, seems similar. (Win 10 Core, Viewing with PC client)
For me, I notice this happens when the Q is less than the screen length. When the Q is longer than the screen, the Now playing line is tight to the top and stays there.
When the Q gets below the length of the screen, then it looks like this
Notice that part of Q history is now showing. At this point, the Now Playing line will just keep descending and not rolling up.
If you add enough new material to increase the Q length longer than the screen the Now Playing line will “snap back” to the top, usually. Like so,
However, I have had it once or twice not “snap back” and still had the Now playing line move down past the screen.
It’s more like the picture you show with lots of history visible. Regardless it is brand new behavior since 537 and annoys the crap out of me.
My queue may not have been longer than screen length (10" iPad) and before 537 I never had an issue, not once ever. Monday as a song ended it stayed on the screen as history a few more played and they were also visible as history. One time I looked down and I was showing tracks from 1 day previous and zero queue tracks visible, just the jump to currently paying track dialog. I sure hope this can be fixed as I will not always have a queue list longest than screen. We’ll see what happens tonight, I generally listen 6 hours straight.
@Rugby Listened a lot last night, warmed the system up using my android phone as roon remote (android 10.3) selected a long playlist so the queue was very long. As a song ended it moved up to history but remained visible, as more songs ended the history pushed the queue down to the point you could not see it anymore unless you hit jump to playing.
Then while listening I used my 10" iPad as remote as long as the queue was longer than the screen it generally behaved normally, completed song moved to history up and off screen. If queue was exactly screen length or shorter then history fills the screen and queue moves down. At one point history was long enough to fill the screen I looked down and visible history tracks was from Monday’s session, not sure what I did to cause that. Then I left queue to look for another album and when I returned the screen snapped back so currently playing was at the top of the screen and history was not visible. It appears if I leave the queue look for music then return it generally snapped back to normal, now playing at top and history not visible.
So iPad behaved like your screen shots, android phone (10.3) history kept moving down until now playing was not visible no matter how long the queue was.
Quad, just another user like you. Was just adding my data points for support when they look into what is going on.
It does seem that there is a difference in handling between PC (which I was using)/ Tablet and the Phone UI (which I did not try out).
Same issue and also using simple Windows 10 laptop as core with a single zone for main stereo.
Same problem here on Roon Remote on Win10 and Android Tablet.
Another 7 hour session last night. Queue and history perform just like Daniels screenshots. As long as queue is longer than screen, no part of history is visible and queue advances as you would expect. If queue is shorter than screen length then a tiny part of history is visible at screen top and as current playing ends it moves to history and now is visible pushing queue songs further down screen. What is odd is as soon as the last song in queue begins playing the screen snaps to much deeper in history, for me it was the beginning of Mondays listening session/ end of Fridays listening session. So I was lookings at songs played 2 and 4 days ago. That phenom only occured when the last song in queue began playing.
Hello @Quadman, I followed your steps with both a long queue and a short queue, but could not get the same result. Are you able to upload a video of this behavior?
My next session is tomorrow, I can shoot video then and upload. Do you have any issues with queue? Daniel had the same issue as I along with several others. Been happening since 537 install. Simple system, 1 zone, my primary stereo. Win 19 server PC with roon server core, HQP, Audiophile optimizer 3, fidelizer 8.4 I think. 10" iPad as remote. I have been roon user since 11/2015.
@nuwriy sorry for the delay in posting a video but here is a link that shows what happens on my system when the next to last song in the queue ends and the last song begins. Note the tiny space at screen top showing a touch of history like the second photo Rugby posted above. The jump was to two listening sessions ago (5 days).
Wow, your jump is drastic.
Yes it is quite a jump and it only occurs when the next to last song in the queue ends. Otherwise the queue just keeps moving down and history occupies most of the screen. If my queue is longer than the screen then everything is normal as before the update.
Same here, it is annoying but I correctly assumed I would not be the only one!
Hello @Quadman, I’ve enable diagnostics for your account so we can take a closer look. Once they come in, I’ll pass them over to our team for further analysis. In the meantime, are you only seeing this on the iPad or does it happen on any other remotes you have?
I am leaving town in the AM so won’t listen again until Monday, evening. Since I only use one zone the iPad is my remote 99.9% of the time. I know my android phone (10.3) even with a long playlist (queue) when a song finishes it goes to history but remains visible on the screen. This will keep occurring even when history has pushed the queue off the screen. To see what is playing I have to touch the jump to now playing button. I am not sure what happens on my phone with a short queue and the next to last song ends if it jumps like the iPad. I will try different remote options monday. IPad, android phone, windows 10 laptop and we’ll find out.
A post was split to a new topic: Queue issues build 537
A post was split to a new topic: Queue issues on build 537
@nuwriy long listening session last night, I used my android phone for the first hour and a half, roughly 8:15-9:40 EST, set up some short queue’s and had same behavior, when next to last track ends the screen jumps 2 sessions ago into history (in this case to last week Monday). The android phone even with a very long queue as a song ends it moves to history but remains visible on screen, this continues until history has pushed the queue off of the screen.
At 9:45 EST I switched remote to my windows 10 pro laptop and set up some short queues so at 9:45 and 9:49 PM EST when next to last song in queue finished the screen jumped back to 2 sessions ago.
The rest of the evening I used my normal iPad as remote and forced some short queue’s between 9:55-10:05 PM EST again same jumping behavior.
My system starts with an ATT Modem (Pace 5268) that connects via ethernet to a Asus TM-AC1900 wireless Router. My core PC has a Rosewell AC1900x wifi card to receive signals from the asus. OS is windows server 2019, I also run Audiophile optimizer 3.0 and fidelizer pro 8.4 (these have been mainstays in my system). Roon Core is on this machine as is HQPlayer, Roon sends the signal to HQP which upsamples it to DSD512, I have been doing this since 2016. PC connects to Dac (T+A Dac8DSD) via USB.
Hello @Quadman, thanks for all the testing for this! I’ve enabled diagnostics for these devices and will add the video to our internal ticket. I’ll be in touch shortly!