Viewing entire comments tag in MP3s

[Bilgus]

After a little more thought and not looking too closely at the current code
I think we could just use buflib to manage the static buffer and then you just need
to worry about which buffers are higher priority

but if you are going that far you might as well take it all the way and just make it buflib allocated memory too


I really dislike the idea of extend tags for comments
 

[Frankenpod]

where does it end 1000 char comments or 1000 megs?

IDK after that maybe make a chunking display in the theme engine?

or just call it good enough for most cases

My impression is most podcasts have 300-1000 character comments.  Maybe there's a way to write a script to look at a lot of them and find what the range/average is (but at the moment I can only copy the comments to a text editor and do a character count, which is time-consuming.  Typical BBC podcasts I've looked at seem to have comments 700-1500 characters long).  The current situation thanks to Chris_S seems like an acceptable compromise, though I don't know how tight memory is for targets with 32 or 64mb and whether there is a downside to going any higher.

  Not sure what a 'chunking display' means, unless it means chopping longer comment fields up into substrings?  I don't understand the details of how tag reading works in Rockbox, but would that still not need a longer string capacity to get access to the full comment field in the first place?

When you say you dislike 'extend tags for comments', do you mean 'extending tags for comments' or 'extended tags for comments', and do you mean 'within rockbox' or just that you dislike podcasters using comment tags in the way they seem to do?

[Bilgus]

 I mean extended tags like having Cmt0 Cmt1 Cmt2
I feel like that is a burden all the way around when it should just work

The other issue I have with just increasing the buffer is that its static and gone forever when it could be either managed static or totally allocated from the start
..its not a longterm solution