Support and General Use > Audio Playback, Database and Playlists

Playing and browsing from the file browser has become sluggish on Clip+

(1/2) > >>

Carlo:
Opening a new topic for visibility as I've previously only reported this issue as a reply on my previous post about the data abort bug.

Since the recent playlist changes have been implemented, I've noticed that playing a file through the file browser from a larger directory (500+ songs) for the first time now takes several seconds of "Loading..", instead of being instantanous like before, and navigating said directories feels quite sluggish as scrolling stutters quite often.

This happens even on the most recent daily builds, tested on several Clip+ devices, and with older builds from before mid-january the browsing and playing speed is fine.

For comparison, the old "[BugFix] playlist.c DIRCACHE stop scanning when changing indices" build from 2023-01-12, which doesn't have the data abort bug, can play files from large directories and navigate their content without any speed issue. That one was the last "true" good build for me (I've resorted to going back to it on my daily driver), as the following ones either have the data abort bug, or navigating larger directories with the file browser is noticeably laggy and there's a significant "Loading.." delay when playing files.

I understand the data abort bug entailed modfying how the playlist is memorized, however after the fixes navigating larger directories and playing files from the file browser has become objectively painful.

rdtyphn:
I wrote about having a similar issue with my current rockboxed player (Hifiwalker H2) in the New Ports section of the forums.
Hopefully there will be a solution.

chris_s:

--- Quote from: Carlo on May 25, 2023, 05:40:15 PM ---Since the recent playlist changes have been implemented, I've noticed that playing a file through the file browser from a larger directory (500+ songs) for the first time now takes several seconds of "Loading..", instead of being instantanous like before, and navigating said directories feels quite sluggish as scrolling stutters quite often.

--- End quote ---
I could be wrong but that feels like two different issues. Removal of in-RAM directory playback shouldn't have caused sluggish directory navigation?

Carlo:
I can't rule out that the sluggish navigation is caused by a separate issue from the aggravating "Loading.." delay when playing a new file. The only thing I can say is that the playlist behavior and performance was absolutely flawless before the changes in mid-january and the subsequent introduction of the data abort bug and its attempted fix.

Again, I went back to using the "playlist.c DIRCACHE stop scanning" build from 2023-01-12 on my Clip+ devices, as builds that cointain the data abort bug fix are practically unusable for me.

Would restoring the old playlist code be out of question? It worked fine, I've never encounter any bug and its performance was absolutely adequate. Is there any meaningful and tangible advantage or improvement in the new code that counterbalances such an abysmal decay (at least for me) in usability?

Carlo:
Is there any planned fix or code rollback for the playlist performance issues introduced by the data abort fix itself? In addition to my Clip+, several older players such as Sansa E200 v1 and v2, Sansa Fuze+ and Creative Zen Mozaic took a severe performance hit, so I was forced to revert to older revisions.

The "Loading.." delay when playing files from large directories is pretty noticeable on newer devices too for me, such as my Fiio M3K and Xduoo X3ii.

Would it be feasible to at least allow users to choose if they wish to store the playlist in ram or in the internal storage? One of the strongest points of rockbox was that it gave new life to older devices with an incredibly snappy interface, while now browsing and playing audio from larger directories with recent builds is really sluggish for me.

Again, I never had a single crash or issue for almost ten years with the pre-mid january builds on several players, so even if the code for the old playlist was a bit garbled, it was nonetheless quick and bug free.

Please, let users decide if they want to store the playlist in ram or on the internal storage instead of being forced to compile builds from older releases to avoid the severe performance hit from the new playlist behavior.

Thanks!

Navigation

[0] Message Index

[#] Next page

Go to full version