Recent dev build breaks my theme(?)

[iPodVT]

Something has changed in one of the recent dev builds that seems to have broken my personal theme's use of %ss and %St.

I have a location and naming convention for the Playlists directory on each of my various iPods that allows me to cache a string that my theme can then retrieve and use to display as a label in the theme's status bar.  This allows each iPod to have a unique label while keeping the theme code generic.  So if my iPod is named iPod_1, I name the Playlists directory PlaylistsiPod_1 and place it in the iPod's root directory.  When my theme goes to draw that iPod's name in the status bar, it retrieves the name string with

%ss(10,-,%St(playlist catalog directory))

which strips away "/Playlists" and leaves "iPod_1".  Or I should say it used to do that.  Yesterday when I updated one of my iPods to the latest dev build I found that the label getting drawn in the status bar is now tsiPod_1, presumably starting with the last two characters of "Playlists".

I suspect this has been caused by the change in fdc3668a6a 23rd Mar 14:37, where enumeration of mounted volumes has been added/changed.

[edit] More to the point, it would seem that every theme's prior use of %St(playlist catalog directory) will be affected.

[Bilgus]

I've got one more patch to this change, could you double check the issue is still happening and i'll fix it in the next few days?

Thanks

[iPodVT]

Okay - I just now updated another iPod from ae01ea7fd9-240223 to 19f21a2b3f-240328 and I am not seeing the problem with that 2nd iPod.  So then I updated the first iPod (the one that demonstrated the problem) from 6e058fe77f-240326 to 19f21a2b3f-240328 and I am still seeing the problem with this first iPod.  Very strange.  I also checked the code in each iPod's .sbs file and it is the same.  The iPod exhibiting the problem is a 5.5 Gen iPod Video and the other is a 5th Gen iPod Video.  Both were originally 30GB but now have iFlash boards with 256GB Samsung Pro Plus microSDs.

I'm not sure what else to do, but at the moment I have to set this aside until later today.  Please let me know if you have any suggestions for what else I might do to resolve this.  Thanks.

[Bilgus]

I assume %st is just using the string length and the extra slashses in one of the paths is causing misalignment like your directory now comes in as ///Playlists and gets stripped by length of 'Playlists' ending up with tsi_Pod

[Bilgus]

make sure you are using this very latest dev build from like 15 mins ago (52e22b25)
I suspect the multiple slashes are the issue

that said I have very inconsistent behavior between devices so its not great to hear its even variable between installs

[iPodVT]

Okay, I'll update them both again.  Standby...

[iPodVT]

Installed Development Version on both.  Still the same - extra chars with one but not with the other.

[Bilgus]

ok thanks for checking, I may have to send you a test version if I don't find anything obvious in the next few days is that the ipod video you are using? and or are you able to compile builds?

[iPodVT]

Both are iPod Video - one 5th Gen, one 5.5 Gen.  Later today I will try another 5.5 Gen and also a 7th Gen Classic.

Thank you!

[chris_s]

You may want to try re-setting the playlist catalog directory on devices updated with the latest build.

[iPodVT]

Yes, yes, yes - that did the trick.  Thanks again, very much.

[iPodVT]

I'm seeing this problem again with dev build 2b7b4c24d5-240720 on a 160GB iPod Classic (MC297LL/A).  When I select a directory in the File Browser and then use the context menu to set that directory as my Playlists Directory, Rockbox is prepending "/<HDD0>" to the directory's pathname string that gets cached in the .cfg file.  My Playlists Directory is in the iPod's root directory and is named PlaylistsTest_Pod.  The pathname string that is getting cached in config.cfg.new is

/<HDD0>/PlaylistsTest_Pod

I'm also seeing "/<HDD0>" prepended to the pathnames of .txt files when displayed in the Header of the text_viewer plugin.

[speachy]

Is this a "theme breaking" change or is it just a change in expected behaviour?

The ipods (and all other ATA-based devices) had multi-volume support turned on recently, which means that path may now include the volume name.  I'd not expect this to _break_ anything that wasn't already broken on devices that aready had multi-volume support though.

[iPodVT]

Is this a "theme breaking" change or is it just a change in expected behaviour?

I think that it's both.  If the data content of a long standing theming tag's spec gets changed such that themes that use that data are now displaying misaligned data, I would say that the theme has been broken.  But I also acknowledge that my manipulated use of that data [ %ss(10,-,%St(playlist catalog directory)) - usage/purpose specified in my initial post of this forum thread] is perhaps a bit unorthodox.

Certainly, my theme could be 'fixed' for the current dev build by adapting it to the new data content, but then it would be broken if/when used with older releases/dev builds, or when used with future builds if that data content gets changed again.

I'm curious to know what the expected theming use of %St(playlist catalog directory) is or was?  I'm guessing that since I'm the only person (that I know of) who has commented on this, that tag is very little used if at all.  As well, since my theme is unpublished and I am the only user of it (albeit on more than a few iPods), I think the expanded multi volume functionality of Rockbox is more important than having an accommodation applied in code for the sake of my theme.  I'm mainly posting this now because I previously raised the same concern several months ago when I began this forum thread and the problem was resolved in that instance.

Someone (I can't remember who) recently posted that a new config setting was in the works whereby a user could cache text data for retrieval by a theme.  If/when that becomes available, my current use of %ss(10,-,%St(playlist catalog directory)) would no longer be necessary and this conversation would more or less become moot.  Perhaps that setting was already included in a recent dev build and I missed it?

Is there a theming tag that returns the numeric length of a setting's string?  I haven't been able to find it.  Having that, I could calculate rather than hard code the starting char of the substring I want to display and then it wouldn't matter what volume name/ID info is or isn't prepended onto the front end of a pathname.

Finally (and I apologize for being so long-winded) I want to repeat that I'm also seeing "/<HDD0>" prepended to the pathnames of .txt files when displayed in the Header of the text_viewer plugin.  I have to say than I think that's ugly, but I can live with that.  I know..., "picky, picky, picky..."

Thanks.

[iPodVT]

The ipods (and all other ATA-based devices) had multi-volume support turned on recently, which means that path may now include the volume name.  I'd not expect this to _break_ anything that wasn't already broken on devices that aready had multi-volume support though.

Rereading that last sentence I now see what you mean:  my method for caching and retrieving a player name wouldn't work as I intend for both devices with and devices without multi-volume support.  It seems that my best course of action would be to abandon my use of %ss(10,-,%St(playlist catalog directory)) and instead wait/hope for your new "playername" setting to become available.

Again, thanks.