|
|
Post by icemanjkh on Mar 5, 2013 6:48:42 GMT -5
As of the 1.4.7 update (can't confirm if it happened previously), it seems that using the seekbar causes the track time (elapsed, remaining, etc) to show incorrectly.
If I don't touch the seekbar and just let the track play, the correct times are shown.
I had a track that I skipped forward to about 95% (using the seekbar, not FF). GMMP skipped the music forward (but not to 95%, even though the elapsed time went to ~95% of the track length time). GMMP kept playing the song and the elapsed time kept counting (well past the actual track length time) - the time shown by GMMP wasn't actually where the seekbar 'seeked' to.
The seek bar seems to play from a track position that's LESS than the bar is showing, yet the 'time elapsed' appears to correctly correlate with the seekbar (but continues to count well past the end of the track).
Cheers
J
EDIT: While confirmation testing this bug I managed to get two tracks playing at the same time :s.
To reproduce this: Star playing a song and seekbari tap at the 99% mark for the current song and let it play beyond the reported track length (ie: get to 0:00 time remaining, yet the track is still playing). Then go to queue and start another song playing. Both songs will play. I believe this is because GMMP believes the first song is already finished given it's gone beyond its reported track length.
|
|
|
|
Post by GoneMAD on Mar 5, 2013 9:13:08 GMT -5
yes total time is just an estimate. The tagging library gmmp uses will calculate the duration instead of reading it from the tags. I just havent gotten around to changing that
as for playing 2 at the same time.. i'll try to reproduce that.. im not quite sure how it would happen because there are tons of safeguards to prevent it (previous music is shutdown before playing a new one and whatnot)
could you send in an error report so i can get your settings in order to reproduce? prefs -> general -> error log -> send report
|
|
|
|
Post by icemanjkh on Mar 5, 2013 15:28:45 GMT -5
Sure thing. Report sent. (I presumed that "Email" referred to my email address, not where to send it to.)
Regarding the tag time vs elapsed time, in some cases, music played more than 45 seconds after the time remaining was at zero (so there appears there was a great deal of error vs the actual location of the track)
This bug was noticed on a Nexus 7 while in landscape mode.
When I tried it reproduce on my Galaxy S3 I couldn't get the seekbar bug to occur (neither portrait or landscape mode).
|
|
|
|
Post by GoneMAD on Mar 5, 2013 17:06:57 GMT -5
yes the email is your address.. its required due to people submitting error reports with very little information or asking a question and expecting me to magically know how to contact them haha
45 seconds sounds really extreme. I've only ever seen it go over around 1-5 seconds.. usually 1-2.. which makes sense if the length is just an estimate.
When it looked like it was past the end of the track, would the seek bar be all the way to the right?
I did mess with the time calculations in the last update to try and make it more accurate since before it would show the decode time (which was always 1-2 seconds ahead because of buffering and whatnot) instead of the playback time
2 songs at the same time is probably a weird crossfade bug that might be related to the bad timings... crossfade is heavily dependent on the position in the track.. so if that is off i could see a situation where the crossfade gets stuck at like 50% each so you can hear both songs playing
|
|
|
|
Post by GoneMAD on Mar 5, 2013 18:52:32 GMT -5
also can you reliable reproduce getting 2 songs to play at once?
|
|
|
|
Post by icemanjkh on Mar 6, 2013 4:48:33 GMT -5
yes the email is your address.. its required due to people submitting error reports with very little information or asking a question and expecting me to magically know how to contact them haha Just checking. My email was provided.  Definitely had +45 seconds in a few instances. Yes. Could be. I believe it's related to xfading or the time remaining. Yes, I can reliably reproduce the 2 songs at same time issue. Sometime GMMP will crash if I try FF/REW whilst both songs are playing (understandable really). I rebooted my N7. Still happens. Also I just checked and the issue exists in portrait as well as landscape. |
|
|
|
Post by icemanjkh on Mar 6, 2013 6:25:27 GMT -5
Also, with either of the shuffle modes turned ON, GMMP correctly moves to the next track when the time reaches zero (even though the track is not actually at the end).
If I turn shuffle ON after the track has passed the zero time, it will immediately skip to the next track, as if it were recognizing that it should have moved on.
Note: In all cases, the error is due to me interacting with the seekbar and putting it at ~95%. Tapping on 95%, dragging to 95% and dragging to 100% and then backing off to 95% (prior to lifting my finger) all result in this issue.
|
|
|
|
Post by GoneMAD on Mar 6, 2013 10:23:14 GMT -5
With shuffle on and crossfade it will use the time to start the crossfade and since it thinks its at the end it just finishes the crossfade immediately. With shuffle off it just waits until the decoder is finished decoding the file, so it doesnt factor in the time at all
Do these tracks you are playing around with happen to be part of a cue file? I remembered this morning that the timing on cue tracks are REALLY off
"Note: In all cases, the error is due to me interacting with the seekbar and putting it at ~95%. Tapping on 95%, dragging to 95% and dragging to 100% and then backing off to 95% (prior to lifting my finger) all result in this issue."
dragging on the seek bar will not do anything until you release your finger, besides adjust the position timer (that is purely a UI change.. the rest of the system is still thinks it the old time). Do me a favor and turn off crossfade and see if you can still get the 2 tracks playing at the same time. If you cant, turn crossfade on and then turn off the eq(if you use it) and try again. There are 4 possible "paths" that the audio can go. CF on EQ on, CF off EQ off, CF on EQ off, and CF off, EQ on. Being able to narrow that down would help
|
|
|
|
Post by icemanjkh on Mar 6, 2013 15:52:10 GMT -5
With shuffle on and crossfade it will use the time to start the crossfade and since it thinks its at the end it just finishes the crossfade immediately. With shuffle off it just waits until the decoder is finished decoding the file, so it doesnt factor in the time at all I figured something like that was happening. No. They are MP3. I tried another album (made just happened to be made of MP4 files) and I could not get the issue to occur (even with Crossfade on). I tried yet another album (of MP3s), issue occurred again. "Note: In all cases, the error is due to me interacting with the seekbar and putting it at ~95%. Tapping on 95%, dragging to 95% and dragging to 100% and then backing off to 95% (prior to lifting my finger) all result in this issue." I realised this. Just trying to be as comprehensive as possible. Crossfade ON, EQ ON: Can play 2 songs at once. Crossfade ON, EQ OFF: Can play 2 songs at once. Crossfade OFF, EQ ON: First song stops and 2nd song starts to play (ie: Only 1 song plays at a time). Crossfade OFF, EQ OFF: First song stops and 2nd song starts to play (ie: Only 1 song plays at a time). Seems crossfade is having an effect. |
|
|
|
Post by GoneMAD on Mar 6, 2013 16:07:34 GMT -5
alright thanks.. i'll hopefully be able to reproduce the 2 songs playing at the same time
one last thing to try for the weird timings. Go to audio -> playback -> uncheck opensl. See if that makes the timing on mp3 any more accurate. I've learned over the last few months that OpenSL is very buggy so i wouldnt be surprised if its reporting back a bad time. If mp3 and aac wasnt so patented I would just provide my own solution instead of relying on what google provides
|
|
|
|
Post by icemanjkh on Mar 6, 2013 16:16:28 GMT -5
No problem.
I have been running with OpenSL turned OFF. It caused issues on my N7 so it's been off for a while now.
I don't know if this is important/related, but I figured that I should add, I'm using Timur's USBROM (http://rootzwiki.com/topic/37755-timurs-kernel-usb-rom-usb-host-power-management-usb-audio/). Although you may have suspected that.
|
|
|
|
Post by GoneMAD on Mar 6, 2013 17:02:51 GMT -5
ah yea thats cool then
yea i've been in contact with timur.. he was trying to get 24bit/96khz playback working
|
|
|
|
Post by icemanjkh on Mar 8, 2013 17:44:05 GMT -5
Cheers for looking into this.
With 1.4.7, I thought the gapless playback might have been modified to be more (how do I explain it....) 'aggressive' - I noticed some songs cutting in a touch early. I was going to post a thread about it, but it could be related to the gapless/crossfade/seekbar issue, so I'll hold off for now.
|
|
|
|
Post by GoneMAD on Mar 8, 2013 18:17:50 GMT -5
if crossfade is off they just go until the decoder hits the end of the file.. nothing has changed with gapless in awhile
if crossfade is on there is no gapless since the songs overlap
|
|
|
|
Post by nobbysheep on Mar 17, 2013 13:03:22 GMT -5
With 1.4.7, I thought the gapless playback might have been modified to be more (how do I explain it....) 'aggressive' - I noticed some songs cutting in a touch early. I was going to post a thread about it, but it could be related to the gapless/crossfade/seekbar issue, so I'll hold off for now. I've noticed the aggressive nature of gapless as well, but in posting a new thread and trying a couple of things, it seems to be working well with Open SL unchecked, but I see from a previous thread you've tested that. My device is a Galaxy Note 2 running 4.1.2 |
|
