Crazy Queue

[CPngN]

My queue was going crazy today. I delete files, they still show up in the queue but as 0:00 length.. except for one which played 1 more time. Then I stopped and it also finally deleted but stayed in the queue. (I believe it's known that they stay there despite being physically deleted, even from within the app..)

Then it timed out again (can we adjust the 5 minute timeout in a future build? ) and I started from the widget, and my queue was "disordered". Some files that I added previously were not at the end but rather "near" the end. I pushed them back down and listened for a while. Later on I stopped playback, it timed out, I started again, and the queue was back to the way it was (out of order). As if it wasn't saving.
Before I could check into it, I let it time out again and the 3rd time I restarted it zipped past a bunch of songs that looked like they were from the previous queue, wiped out the queue, and loaded an entirely different album by the same artist. ...only I didn't push anything!
I'm hoping the last bit is because I had my hand on the screen and turned it on unknowingly, otherwise it's very ... well, freaky. If and when that happens again I'll send you a log.

[GoneMAD]

yea i can make the timeout length configurable at some point

i'll try some things and see if i can reproduce what you mentioned. I dont test often with the music service timeout because no one really should be using it if they are running froyo or higher. Android does a good job managing memory on its own

Anyway.. a few things. Do you have prefs -> library -> browser -> clean db after deletion enabled? If thats no on and you delete stuff.. yea things will act crazy. You will have dead references and the queue wont get cleaned up... so songs should be skipped if they are attempted to be played. What setting do you have for prefs -> queue -> on queue completion? If thats set to play next folder that is most likely how the next album started playing.. or you could have accidentally done the next album gesture.

and lastly were you playing music that was not scanned into the database? (might happen if you play a folder full of folders from the file browser). In this case the files are added to the internal queue but never saved off in the database. If the file was then deleted, the queue would most likely try to open the file to figure out its duration.. since the file doesnt exist it would stay at 0. If the file was already scanned and in the database, the duration would be retrieved from there

[CPngN]

I have "Clean DB After Deletion" checked ON.
But.. may not have had it one when I wrote that post, so we'll see. Most of the tracks weren't ones I would delete, though.

On Queue Completion is set to Loop Queue.

The next album thing I think was my hand hitting a gesture and switching, so I just disabled all that gesture stuff for now.

I regularly add 1 or 2 daily shows from the browser right into the queue. I thought you said that when you play/add single files they also get added to the database. These are shows that come and go on a daily basis, so I'd hate to have to rescan all the time to make things work right.

One last complaint: queue does not appear to be saved in a permanent way.. when I have to reboot the machine or the battery dies, my queue is completely lost. It would be nice if it were treated as a sort of "current playlist".. in perhaps if we could even have 2+ queues to switch between for different situations. That may be a bit too complicated though.

[GoneMAD]

if the queue disappears on reboot that means you are adding files that are not scanned into the database. If you use the browser it does scanning as you navigate and when you play a folder.. however when you play a folder.. it does not do a deep scan (it will not scan subfolders of that folder you selected)

So either run scans more often or dont play folders containing folders that contain your music

[CPngN]

Nope, only 1 folder which I either pick individual (new) files out of to enqueue or enqueue the entire folder if it's all new. It's also the same folder I have picked out to always bookmark.

Other weird things are happening still too.. I'll launch the app after timing out, and the queue order isn't quite the same (last rearrange changes lost) and my last "song" is enqueued twice. And sometimes if I"m on the 2nd to last track, it jumps to the last one, but at the bookmark position of the previous track.

I'm going to disable the 5 minute timeout and see if it helps (I suspect it will) and if battery life does not change appreciably. I'm on an S3 with 4.1.2 so memory isn't really the issue, but a service doing nothing but sucking away battery is. This may no longer be a big deal (it was "back in the day").
Thanks

[GoneMAD]

anything involving the queue gets backed up straight to the database immediately after the change and i mentioned the only situation that would cause the queue to be lost.. so it sounds like your installation is corrupt. Uninstall/reinstall usually fixes the odd bugs that are impossible for me to fix. As of right now there is one bug that i have fixed locally and have not released it yet.. but otherwise all the bug reports i receive are either issues caused by the android sdk.., manufacturer specific code that is crashing and my app happens to catch it and get blamed for the crash, or bugs caused by corrupt hardware(sdcards)/software/music/tags.

i do recommend turning off the music service timeout.. it is pretty much pointless. Android 2.3 and newer has good memory management so it will free the service if the OS actually needs the memory (and even then it usually caches the service so it can restore it later). Too many people are still in the belief that their device should be using as little ram as possible and that it slows down their phone.

When paused and in the background GMMP will use 0 cpu unless you have some of the automatic scanning setup in which case that will still run

[CPngN]

I've disabled the 5 minute timeout and noticed that I have had it set to scan at every service startup this whole time. Unfortunately if I l leave it "running" then it won't be triggered when I "load the app". This morning I had to manually exit the app so it wouldn't auto-play when I connected to BT in the car. I thought manual exits were saving the queue ok, but no.. it was lost. Bookmark was also lost on the track I was playing before.

I'll try un/re-installing and see if that helps. Otherwise I'll have to bail, as I can't be reloading my shows, finding the last one I was at, and refinding the position in a 3 hour mp3 while in the car every day.

[CPngN]

OK I un/re-installed and manually set everything up instead of loading old settings from backup. *crossing fingers*

[GoneMAD]

Sept 5, 2013 13:10:28 GMT -5 CPngN said:

I've disabled the 5 minute timeout and noticed that I have had it set to scan at every service startup this whole time. Unfortunately if I l leave it "running" then it won't be triggered when I "load the app". This morning I had to manually exit the app so it wouldn't auto-play when I connected to BT in the car. I thought manual exits were saving the queue ok, but no.. it was lost. Bookmark was also lost on the track I was playing before.

I'll try un/re-installing and see if that helps. Otherwise I'll have to bail, as I can't be reloading my shows, finding the last one I was at, and refinding the position in a 3 hour mp3 while in the car every day.

From doing bluetooth testing i've found that the car actually sends a "PLAY" button intent when it detects a bluetooth audio connection being established. Its pretty annoying

Yea I will say with 99.9% certainty there are no bugs saving the queue assuming these are files that show up in the library. Corrupt install is really the only explanation. If there were errors they would show up in the error log within a few seconds of you adding to the queue