Buffer level in WPS

[NiHaoMike]

In the debug menu, the various buffers can be viewed. It would be nice if the disk buffer level could be displayed in the WPS. (As for actual application, it's really another thing to show. But hey, I'm an engineer.)

I would assume the actual implementation shouldn't be very difficult since the code to check the buffer already exists. But I mainly deal with hardware, not software.

[Llorean]

Generally there needs to be a reason such information is useful to the normal user before more tags are added. While one can't argue that Rockbox is even remotely as lean as it used to be, there's still general benefit in avoiding bloat where possible, so a feature like this seems unlikely. It's more or less purely debug information.

[Yotto]

*EDIT for clarity*

As a user, I've wanted this for some time. I listen to podcasts, and frequently want to delete the current podcast while I'm listening to it, some time in the last 10 minutes or so when it's convenient (Say, while stopped at a red light). I don't want to do this unless the mp3 file is fully loaded, and currently there is only one way to do this: have a playlist window up. Playlists can show if the NEXT song is loaded, and I can infer that that means that the CURRENT song is loaded, but this is a little clunky.

A tag (with conditional) would make this much easier to both code and read. %?bf<if 0|if 1|if 2|...|if more than those> would be perfect.

I've also wanted a "Fill the buffer" option somewhere easy to get to, but that's for another thread.

[Llorean]

Isn't the "Next track Title" ID3 tag only visible when the next track is on buffer?

Wouldn't that be all you need to know when you can safely delete the current one?

The current buffer level wouldn't tell you anything about what's in it, just how full it is. If you've got about 8 minutes of audio left, and the buffer is 30% full, do you know much?

[JdGordon]

the next tracks id3 should *always* be visible (it is loaded seperatly for the track after the last one in the buffer).

it sounds like it would be better to change the "delete file" behaviour on the current playing track to delete after it finishes instead of immediatly.

[Yotto]

In the debug buffer, there's a "track count" that I have always thought was the number of files buffered. It counts down with each track and then counts up while buffering. It is possible that NiHaoMike is discussing a different thing to read, but this is what I was talking about. Sorry for the confusion.

I don't see any time indicator on that screen. I can't see a reason to know that number, but that doesn't of course mean that there is no such reason.

And when talking about next track names vs id3 tags, I'm specifically talking about the playlist viewport. You can, while displaying that viewport, display the id3 tags if they're loaded and the file name if they're not loaded. I've been using that functionality to determine if the next track is loaded (presuming it wouldn't load unless the current track is fully loaded, and therefore safe to delete).

I'm thinking of an idea on how to use the playlist viewport to more concisely show that the current track is fully loaded. It won't be as pretty, code-wise, as a simple tag but I think that it will work. Especially if you can display multiple playlist viewports at the same time.

[JdGordon]

like I said above. You cannot use the availability of the next tracks ID3 for anything other than showing that info. It is an incorrect assumption that the current track is finished buffering if that is available.

The numbers in the debug screen are not very useful to anyone not interested in debugging playback, I don't even know what some of those values mean.

[Yotto]

Hrm. I was hoping you meant "for the %Fx tags."

The http://www.rockbox.org/wiki/CustomWPS page is a bit misleading on this. In the "Next Track Info" section, it reads:

Take note that the next song information WILL NOT be available at all times, but will most likely be available by the end of a song. We suggest you use the conditional display tags when displaying information about the next song, just in case.

This at least implies that it's not loaded until the song is buffered.

And in the playlist viewer it is even more explicit:

#  "show if id3" - Skin code to display if the track has been buffered (supported skins explained below)
# "show otherwise" - Skin code to display if the track hasnt been buffered, really only the filename is know at this point.

[pixelma]

A small clarification about the note on CustomWPS about the next track info as I know it:

The http://www.rockbox.org/wiki/CustomWPS page is a bit misleading on this. In the "Next Track Info" section, it reads:

Take note that the next song information WILL NOT be available at all times, but will most likely be available by the end of a song. We suggest you use the conditional display tags when displaying information about the next song, just in case.

This at least implies that it's not loaded until the song is buffered.

the next tracks id3 should *always* be visible (it is loaded seperatly for the track after the last one in the buffer).

Both is true in two cases: The first applies to all targets... sometimes there simply is no next track.

The second is a bit more complicated... there are differences in playback and buffering between software codec targets which do all the decoding on the CPU and the hardware codec targets which have a decoder chip for this (only the Archoses belong to the latter). On software codec targets, the metadata of the next track is always there provided there is one. On hardware codec targets, the next track's metadata is only available if the next track is partially buffered which means only within 1-1.5 minutes before the track change with common MP3 files.

My guess is that this comment is there for a long time already, maybe it could be clarified a bit on CustomWPS, not sure how though. About the new playlist tags - I don't know how they work because I haven't tried yet. But I would assume it uses the next track info the same as the pure next track info does, it would be weird if it implements its own mechanism.

[soap]

You also don't get next track information at the end of a playlist.  This may seem obvious, but if you have folder advance turned on the fact you're technically at the end of a playlist is pretty well abstracted under most circumstances.

[JdGordon]

This should be the final word on when the next track info is avilable.

"Assume never. There are too many factors involved including the developers who might one day completly change the whole thing. Think of it as a nice bonus if that info is available, but assume it wont be."

(Yes, I realise I'm contradicting my previous post, this one is with my user support hat on, the other was with my developers hat on :p )