[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rockbox
Subject:    Playing and browsing from the file browser has become sluggish on Clip+
From:       Carlo via rockbox <rockbox () lists ! haxx ! se>
Date:       2023-06-11 11:49:55
Message-ID: CANyRZhCtfKBNj_tBfX6D-30F2DDNEVXxV1K2G7UL7j1KAFgWqQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Since the recent playlist fixes for the data abort bug 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. Older builds from before mid-january does not show this behavior
as the browsing and playing speed is fine.

For example, the "[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 or hiccups. 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 after its fix 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 for me.

I'm aware the playlist was saved in RAM before the fixes, however it always
worked fine for years without a single crash (until the data abort one),
and now I'm basically forced to use an older build on my Clip+ players as
the significant playing and browsing delays introduced by the recent
playlist changes are aggravating.

Would it be feasible to go back to the playlist code before the chunk_alloc
changes were implemented? It worked fine without bugs or other performance
issues.

Thanks.

[Attachment #5 (text/html)]

<div dir="ltr">Since the recent playlist fixes for the data abort bug have been \
implemented, I&#39;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 
&quot;Loading..&quot;, instead of being instantanous like before, and navigating 
said directories feels quite sluggish as scrolling stutters quite often.
 <br><br>This happens even on the most recent daily builds, tested on 
several Clip+ devices. Older builds from before mid-january does not show this \
behavior as the  browsing and playing speed is fine.<br><br>For example, the \
&quot;[BugFix] playlist.c DIRCACHE stop scanning when changing indices&quot; build  \
from 2023-01-12, which *doesn&#39;t* have the data abort bug, can play files  from \
large directories and navigate their content without any speed  issue or hiccups. \
That one was the last &quot;true&quot; good build for me (I&#39;ve resorted to  going \
back to it on my daily driver), as the following ones either have  the data abort \
bug, or after its fix navigating larger directories with the file  browser is \
noticeably laggy and there&#39;s a significant &quot;Loading..&quot; delay  when \
playing files.<br><br><div>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 for \
me.<br></div><div><br></div><div>I&#39;m aware the playlist was saved in RAM before \
the fixes, however it always worked fine for years without a single crash (until the \
data abort one), and now I&#39;m basically forced to use an older build on my Clip+ \
players as the significant playing and browsing delays introduced by the recent \
playlist changes are aggravating.</div><div><br></div><div>Would it be feasible to go \
back to the playlist code before the chunk_alloc changes were implemented? It worked \
fine without bugs or other performance issues.</div><div><br></div><div>Thanks.<br> \
</div></div>



--
Unsubscribe: http://lists.haxx.se/cgi-bin/mailman/listinfo/rockbox
FAQ:         http://www.rockbox.org/twiki/bin/view/Main/GeneralFAQ
Etiquette:   http://www.rockbox.org/mail/etiquette.html


[prev in list] [next in list] [prev in thread] [next in thread]