Rockbox Technical Forums

Support and General Use => Theming and Appearance Customization => Topic started by: chris_s on January 31, 2019, 05:59:06 PM

Title: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on January 31, 2019, 05:59:06 PM
Commit fe95127c45bcb330d54c701b937a497649082a4d on Github (https://github.com/Rockbox/rockbox/commit/fe95127c45bcb330d54c701b937a497649082a4d) that was uploaded today will display the default status bar on top of custom status bars in the newly added screen that displays info about a playlist's playing time  (see attachment).

The status bar needs to be enabled (set to "top" or "bottom") to see the effect.

Removing lines 433 (https://github.com/Rockbox/rockbox/blob/fe95127c45bcb330d54c701b937a497649082a4d/apps/onplay.c#L433) and 436 (https://github.com/Rockbox/rockbox/blob/fe95127c45bcb330d54c701b937a497649082a4d/apps/onplay.c#L436) seems to fix the issue and this solution will also continue to work with the default status bar, as far as I can tell.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on January 31, 2019, 08:09:38 PM
Oh, and another thing regarding this commit:

There appears to be an off-by-one error. When playing the first track in a playlist, it will display "Track 0/n" and for the last one "Track n-1/n"

In line 292, it should probably be  pti->curr_playing+1
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: speachy on February 03, 2019, 07:40:10 PM
Thanks for the heads-up!    Here's the proposed patch:

http://gerrit.rockbox.org/r/#/c/2070/

If that looks sane to you (ideally you could test it!) I'll commit it.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on February 03, 2019, 08:24:57 PM
Awesome – looks/works great! Successfully tested this and switched between status bar settings on the hardware I have at hand (iPod 4G), using both the default status bar theme and custom ones. Also works fine in the iPodVideo, Rocker and Clip Zip simulators I’ve (sort of) randomly picked.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: speachy on February 03, 2019, 08:32:57 PM
It's merged.  New builds should be up within an hour..
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on February 05, 2019, 06:58:27 AM
Nice! Definitely fixes the issues. By the way, and unrelated to the fix, I've now noticed the info isn't correct anymore after you've reshuffled a playlist (without Shuffle mode being enabled) and possibly after modifying the playlist in other ways.    :D :-X
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Frankenpod on February 05, 2019, 10:20:16 AM
It's good to have new features added.  Glad people are still working on such things.

Maybe regarding the info not being correct after  a reshuffle, presumably it would be possible to set a flag upon a reshuffle that would cause the information to be recalculated, immediately or the next time it's viewed?  I'm guessing it would be a lot more awkward to track all other possible playlist changes, but perhaps that one fix would be relatively simple?
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on February 05, 2019, 10:21:48 AM
It's good to have new features added.  Glad people are still working on such things.

Maybe regarding the info not being correct after  a reshuffle, presumably it would be possible to set a flag upon a reshuffle that would cause the information to be recalculated next time it's viewed?  I'm guessing it would be a lot more awkward to track all other possible playlist changes, but perhaps that one fix would be relatively simple?
Maybe I wasn't being clear. The information is recalculated each time the screen with the info is displayed, thus taking quite a while each time depending on the size of the playlist. It's just that the calculation (i.e. the actual algorithm) is incorrect once you've reshuffled the playlist.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Frankenpod on February 05, 2019, 10:32:36 AM
It's good to have new features added.  Glad people are still working on such things.

Maybe regarding the info not being correct after  a reshuffle, presumably it would be possible to set a flag upon a reshuffle that would cause the information to be recalculated next time it's viewed?  I'm guessing it would be a lot more awkward to track all other possible playlist changes, but perhaps that one fix would be relatively simple?
Maybe I wasn't being clear. The information is recalculated each time the screen with the info is displayed, thus taking quite a while each time depending on the size of the playlist. It's just that the calculation (i.e. the actual algorithm) is incorrect once you've reshuffled the playlist.
Ah.  Sorry, misunderstood.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: chris_s on February 05, 2019, 10:46:55 AM
It's good to have new features added.  Glad people are still working on such things.

Maybe regarding the info not being correct after  a reshuffle, presumably it would be possible to set a flag upon a reshuffle that would cause the information to be recalculated next time it's viewed?  I'm guessing it would be a lot more awkward to track all other possible playlist changes, but perhaps that one fix would be relatively simple?
Maybe I wasn't being clear. The information is recalculated each time the screen with the info is displayed, thus taking quite a while each time depending on the size of the playlist. It's just that the calculation (i.e. the actual algorithm) is incorrect once you've reshuffled the playlist.
Ah.  Sorry, misunderstood.
All good. :) Totally agree with the rest of your post. Great to see new/old (https://www.rockbox.org/tracker/task/6338) (:D) features added and it seems very useful to be able to quickly tell how much time has elapsed and (especially) is remaining in the current playlist.

In fact, and this may be a matter of taste, but at least for my own purposes, I will condense the screen down to just that info (even though the rest of the computation appears to more or less come “for free”) as the rest seems redundant and instantly out of date (track elapsed/remaining) or doesn’t seem like something I would ever have reasons to be concerned about (storage and bitrate statistics).  Also prevents scrolling on smaller screens with a larger font:

Code: [Select]
Elapsed: 3:34:19 hr
Remaining: 02:46:29 hr
Total: 06:20:48 hr
Completed: 56%


But it’s possible that others may have valid scenarios where the additional info may come in handy…
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Frankenpod on February 05, 2019, 12:08:35 PM
If I were making 'requests' (which seems presumptuous, I know), it would be maybe to have a simple graphic representation of elapsed/remaining time.  Just a bar of two colours/b&w would do.  I  implemented a graph like that with my attempt at a disk usage display (but I ran out of steam on that idea when my unix box died).

Also I wonder if it would be possible to only update the total playlist information when something changes?  Thus avoiding the delay while it calculates it.  But I guess that would be very involved, to check for all the ways the playlist could be changed.  Probably asking too much.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Bilgus on February 05, 2019, 12:12:51 PM
As long as the playlist control file is valid it is relatively easy to see how the playlist was transformed
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: speachy on February 05, 2019, 01:43:19 PM
If I were making 'requests' (which seems presumptuous, I know), it would be maybe to have a simple graphic representation of elapsed/remaining time.  Just a bar of two colours/b&w would do.  I  implemented a graph like that with my attempt at a disk usage display (but I ran out of steam on that idea when my unix box died).

Also I wonder if it would be possible to only update the total playlist information when something changes?  Thus avoiding the delay while it calculates it.  But I guess that would be very involved, to check for all the ways the playlist could be changed.  Probably asking too much.

The textual representation can be voiced... a graphic view, not so much.

But yeah, reworking things so that playlist duration is computed on the fly (ie with each playlist time) would require some substantial work in the bowels of the playlist manipulation code.   Hmm.  Will have to think about this..
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Frankenpod on February 05, 2019, 02:29:28 PM

The textual representation can be voiced... a graphic view, not so much.

But yeah, reworking things so that playlist duration is computed on the fly (ie with each playlist time) would require some substantial work in the bowels of the playlist manipulation code.   Hmm.  Will have to think about this..

I was thinking, as far as graphics go, something like the attached pic (my aborted attempt at a plug-in, which I got running on my own ipod).  But that was a plug-in, maybe as such it has access to 'draw' functions that code in the main part of rockbox doesn't?


I'm sure making it only update data when necessary would be a really tiresome job and quite likely not worth the effort.  It's a nice addition as it is.
Title: Re: Latest commit (FS6338: Playlist playing time) – Issue with custom status bars
Post by: Frankenpod on February 23, 2019, 09:16:27 AM
If I were making 'requests' (which seems presumptuous, I know), it would be maybe to have a simple graphic representation of elapsed/remaining time.  Just a bar of two colours/b&w would do.  I  implemented a graph like that with my attempt at a disk usage display (but I ran out of steam on that idea when my unix box died).

Also I wonder if it would be possible to only update the total playlist information when something changes?  Thus avoiding the delay while it calculates it.  But I guess that would be very involved, to check for all the ways the playlist could be changed.  Probably asking too much.

The textual representation can be voiced... a graphic view, not so much.

But yeah, reworking things so that playlist duration is computed on the fly (ie with each playlist time) would require some substantial work in the bowels of the playlist manipulation code.   Hmm.  Will have to think about this..

From looking at the code (and I really struggle with trying to figure out much about the existing code-base) it seems that the reason a graphic view would be hard is because the option works by using the menu-displaying-routine for displaying the results?  I suppose that's just the easiest way to do it?  To have a graphical output would need a separate routine for displaying that data as a distinct output page, rather than just treating it as a menu (which it strictly isn't, as the entries aren't really options to select).

No criticism intended, I was looking to see if I could add a little graphic to it myself, but I seriously am not good at working out how the existing code works.  I have a routine for drawing a bar chart, but that can't go into a menu, and I really can't figure out how to make the option create a separate output page rather than putting the information in a sub-menu.