Jump to content

Please return to old seek or give us the legacy seek option


Js78955

Recommended Posts

@maxmp

Please return to old seek or give us the legacy seek option,v2 build 588 and below works fine with seek,but your new seek in alpha and beta build does not seek my mp3 songs what it does is restart the songs again from the start whereas progressbar stays there and continue from where i took to seek,please add option in settings to use legacy seek,i hate your new seek

Link to comment
Share on other sites

  • 4 weeks later...
  • 2 weeks later...

you guys are not understanding my issue @andrewilley @clever_man

the problem is not with the design of the seek,the issue is with the algorithm (CODING) of the new seek after v588 all version cant seek my songs properly and it starts the song from the beginning

i recorded video,even i have mentioned @maxmp many times but he keeps ignoring my requests i got 17GBs of songs and for those i had to use old v588 due to this issue please fix it or add some legacy seek algo in the app or tell me what i need to change to support the working seek in new v3.x.x build please man bring the old seek algo

 

VIDEO describing the issue :- https://www55.zippyshare.com/v/DvjtppCI/file.html

Link to comment
Share on other sites

28 minutes ago, Js78955 said:

I wonder if it is a problem with using 48khz mp3 files. Does it happen with any other formatting?

Also, have you tried using the "Static Seekbar" option? Does it make any difference?

Lastly, try the 3rd party skins, it couldn't hurt to try it:

 

Link to comment
Share on other sites

Yes it depends on songs,even 128kbps doesnot seek but other 128kbps can seek whereas old v588 build can seek every single song even jetaudio plus music player can seek every single song,the developer added new seek algo in v3 alpha or beta none of them works

Link to comment
Share on other sites

It's most likely large album art combined with (for whatever reason) the tag data not being understood by PA in terms where in the file (i.e. the offset) the music itself begins.

To test if it is this, could you try removing the embedded cover art from one of the tracks which causes this problem (using an MP3 tag editor) and see if PA can find the start and end (and length) correctly with the new file?

Andre

Link to comment
Share on other sites

23 hours ago, Js78955 said:

you guys are not understanding my issue @andrewilley @clever_man

the problem is not with the design of the seek,the issue is with the algorithm (CODING) of the new seek after v588 all version cant seek my songs properly and it starts the song from the beginning

i recorded video,even i have mentioned @maxmp many times but he keeps ignoring my requests i got 17GBs of songs and for those i had to use old v588 due to this issue please fix it or add some legacy seek algo in the app or tell me what i need to change to support the working seek in new v3.x.x build please man bring the old seek algo

 

VIDEO describing the issue :- https://www55.zippyshare.com/v/DvjtppCI/file.html

Thanks for the report. To debug such tracks, the track itself is needed.

But it's true, not all mp3 tracks can be reliable seeked due to absence of "seek" data. The only possible solution is to decode whole track to the seek position, Poweramp can do that but its heuristics don't allow too much such seeking due to high cpu/battery demand. It's OK solution for PC connected to the wall, but on phone we want to conserve battery, this is why such approach is taken.

Still the problematic mp3 may be useful for tests, please PM me a link just for test purposes, thanks!

Link to comment
Share on other sites

11 hours ago, andrewilley said:

It's most likely large album art combined with (for whatever reason) the tag data not being understood by PA in terms where in the file (i.e. the offset) the music itself begins.

To test if it is this, could you try removing the embedded cover art from one of the tracks which causes this problem (using an MP3 tag editor) and see if PA can find the start and end (and length) correctly with the new file?

Andre

i have tested after removing embedded 800x800albun art still the issue persists

10 hours ago, maxmp said:

Thanks for the report. To debug such tracks, the track itself is needed.

But it's true, not all mp3 tracks can be reliable seeked due to absence of "seek" data. The only possible solution is to decode whole track to the seek position, Poweramp can do that but its heuristics don't allow too much such seeking due to high cpu/battery demand. It's OK solution for PC connected to the wall, but on phone we want to conserve battery, this is why such approach is taken.

Still the problematic mp3 may be useful for tests, please PM me a link just for test purposes, thanks!


i have sent you two songs one with 48kbps and one with 128kbps which does not work with seek in new version but old v588 build and below does the job properly

well if you seek the song halfway where you can see the frequency is analyzed in Poweramp ,the seek works for example if the song is 3mins and Poweramp shows the frequency static for like 1.2min and after that it is variable and seek works in variable frequency not in static as you see in the video on post, maybe issue in Poweramp to analyze it properly.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...