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

[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]

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.

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!

[rdtyphn]

I also noticed that on my Xduoo X3ii navigation was very sluggish. It was one of the reasons I switched to a hifiwalker H2 but now it's affected by the crashing.

How did you find builds dating back to that time? Until these issues are fixed I'd like to do the same for my devices if possible.

[Carlo]

I'm compiling the source code from a specific git commit, 00c7817c9c326368c2cd89f1e786584283935c9c from 2023-01-12 ("[BugFix] playlist.c DIRCACHE stop scanning when changing indices"), the last bug free one without the massive performance problems introduced by the playlist fixes.

I don't mean to sound ungrateful or unappreciative for all the hard work the devs devoted to the Rockbox project, however all the recent playlist changes should be scrapped and the old code reverted back. The old playlist code was working fine, the new one has severe performance issues even on modern devices without any tangible advantage for the users.

Please, devs, don't ruin Rockbox for all of us!

[rdtyphn]

Any updates on this from the devs? I've been updating my Hifiwalker H2 regularly with the latest build and still have been running into these crashes.
To recap for the past year or two at times there is display corruption and player slowdown with the disk access icon constantly spinning up and eventual hanging of the player on the native port. It seems related to browsing file directories. The error says "exception" TLB refill and about four lines of numbers.

Thanks

[speachy]

There are several folks who use this as their daily driver with no issues, so we're going to need way to semi-reliably reproduce the problem you're seeing if there's any hope of intentionally addressing it.

Eg, does it happen with the latest build, stock theme, and default configuration?    If not, then which setting change leads to this?   Does the specific file(s) matter?   Has the storage device been checked for errors?  etc etc.

[rdtyphn]

Thanks for your reply.
It happens with the latest build. This happens exclusively with browsing the filetree. The specific files do not matter. I have checked the storage device for errors. It seems to happen when scrolling around through lots of file folders but sometimes will happen more quickly while browsing. The screen starts slowing down and showing corrupted looking text. It gets slower and choppier and impossible to browse. Then usually a crash happens. I've attached the screenshot of the crash.

[Carlo]

I've tried the latest rockbox build roughly every month, but the slowdowns - and a few complete hangs (without any "data abort.." error message) - on my daily Clip+ were never truly resolved, so I'm sticking with a version that's stable for me from early january 2023.

Edit: I've just remembered that newer builds routinely crash when updating or recreating the database from scratch on my Clip+. I'm sorry to say that I've given up on updating, the old build I'm using works flawlessly for me and I'm going to stick with it.

[rdtyphn]

Great news, I recently updated to the newest builds for the H2 player. I had some trouble updating because I kept getting a white screen on boot and updated the native bootloader several times. After using the JZtool method I was able to boot rockbox and everything seems stable. I haven't had any freezes and hangs over the past two days which is unusually good.
Thanks

[rdtyphn]

It started happening again with the display corruption and slow browsing.