An album that plays from the DB but not from the File Browser

[iPodVT]

I have an album on my iPods that will play when accessed via the Database or via the Playlists Catalog, but it won't play when accessed via the File Browser.  The album contains eight tracks.  I've tried clicking on each individual track from within the File Browser but none of them will play.  This happens in both the recent experimental dev build ab2af16c7c-240415 running on an iPod mini 2nd Gen and also on dev build 52e22b253d-240329 running on an iPod Video 5.5 Gen.

Here is the 'real' text of the full path to the first track in the album:

/_dtgLIB/The City Of London Chamber Orchestra; Thomas McIntosh, Organ, Harpsichord & Conductor/English Music By Purcell, Arne, Stanley, Chilcot/01 Purcell: "King Arthur," Suite for Strings.m4a

Here is the text of the full path to the same track as it is displayed in the File Browser:

/_dtgLIB/The City Of London Chamber Orchestra; Thomas McIntosh, Organ, Harpsichord & Conductor/English Music By Purcell, Arne, Stanley, Chilcot/01 Purcell_ _King Arthur,_ Suite for Strings.m4a

When I click on any of these tracks in the File Browser, Rockbox shifts to the WPS as expected.  Under "Now Playing" it displays the title and artist of the album's last track, and for the album it just displays _dtgLIB which is the name of my main music directory - located in the root directory - containing the vast majority of the music on my iPods.  Both iPods have the exact same music libraries synced from the same source.  The last track's title is displayed with the substitute characters (as in the full pathname cited above), whereas when I play the same track via the Database or the Playlists Catalog the track's title is displayed with the 'real' text, not with the substitute characters.  Also, the start/current time and end time under the Play progress bar are both 0:00 and there is nothing displayed under "Next Track" (of course).

When I long click on any of these tracks in the File Brower and choose "Show Track Info" from the Context Menu, I get the error message "File/Dir not found" followed by as much of the pathname as will fit in the error message box.  When I long click on the album's directory in the File Browser and choose Properties from the Context Menu I get a display of all the correct info for the directory, including its correct full pathname.

So, is there something about the text of the album's title that is causing this problem?  I'm pretty sure there lots of other tracks in my music library with longer pathnames. 

[iPodVT]

Pursuing the problem further, I did some experimenting with copying and pasting tracks and directories to the root directory, the results of which seem to indicate that the problem is caused by the length of the pathnames to the track files in the album directory.  At least that's my guess.

I previously encountered the same problem and posted about it [https://forums.rockbox.org/index.php/topic,54443.msg251568.html#msg251568].  In that discussion (which was mostly a monologue) Bilgus posted "likely MAX_PATH which is 260 bytes".  In my current problem, the pathname of the first track in the album is 193 characters (perhaps some of those are two byte chars?).

So is 260 the actual MAX_PATH?

A previous question I posed that I don't believe was ever answered is what is the length limit for a single component name (directory or the file itself) within the pathname?

Thanks.

[chris_s]

This appears to be an issue with an incorrect buffer size used by the File Browser when assembling paths. I've cc'd bilgus on a possible fix.

[iPodVT]

Cool - thanks.

[iPodVT]

I just now tried playing this same album via the File Browser on an iPod 7th Gen Classic (A1238 - MC293LL/A) that has dev build 9e802be969-231204 installed, and I did not have any of the problems I described in my above posts using newer dev builds on an iPod mini 2nd Gen and an iPod Video 5.5 Gen.  All three of these iPods have identical music libraries synced from the same source.

So I used Rockbox Utility to install the current Daily Build (labeled 20240420 in the Utility but identified as 123858287b-240418 in rockbox-info.txt) and now I am having the same problems with this 7th Gen that I had with the mini and Video.

So it seems that the bug was introduced sometime after Dec 4, 2023.

[speachy]

So it seems that the bug was introduced sometime after Dec 4, 2023.

You could try the oldest daily build to see if the problem is still present; it'll narrow down the window further.

[chris_s]

Should be fixed now in the very latest build (e5c65a0039)

[iPodVT]

Should be fixed now in the very latest build (e5c65a0039)

I just now installed e5c65a0039, and all of the things that I reported above as not working are now working perfectly.  Thank you very much for the fix and for getting to it so quickly.

So is MAX_PATH in fact 260 bytes?  And is there a sub limit for the individual names of directories and files?

[chris_s]

yes, MAX_PATH is 260: https://github.com/Rockbox/rockbox/blob/e5c65a00392f801e39d7e3287c62bd8e4ec17cda/firmware/include/file.h#L35

Not sure whether that is consistently applied though. I for one am not aware of other limits for path components in general.

There is also MAX_FILENAME (32) and MAX_PATHNAME (80) that are used for settings, specifically:
https://github.com/Rockbox/rockbox/blob/e5c65a00392f801e39d7e3287c62bd8e4ec17cda/apps/settings.h#L42

[Bilgus]

ultimately the limit applies to the whole path, I think the db gets away with some tricks with the names where each component is stored and later re-constituted but I think there is still only 260 chars available once its time to play it so I'm not sure it'd buy you much unless its using the directory cache to open longer paths

one way around this could be a true CWD function (current working directory) or it could even be mounted into the namespace to remove the prefix paths but faster than waiting on that would be to shorten up your filenames

[iPodVT]

Thank you again, chris_s and Bilgus, for being so responsive.

And, yes, I have to try to be more mindful of the verbosity of the Track, Album and Artist names in the Classical Music section of my music library.  But it does serve the purpose of providing some stress testing of limits in Rockbox...

[iPodVT]

yes, MAX_PATH is 260: https://github.com/Rockbox/rockbox/blob/e5c65a00392f801e39d7e3287c62bd8e4ec17cda/firmware/include/file.h#L35

Not sure whether that is consistently applied though. I for one am not aware of other limits for path components in general.

There is also MAX_FILENAME (32) and MAX_PATHNAME (80) that are used for settings, specifically:
https://github.com/Rockbox/rockbox/blob/e5c65a00392f801e39d7e3287c62bd8e4ec17cda/apps/settings.h#L42

It turns out that I have an audio track whose filename (not pathname, but filename!) is 143 chars long (including the filename extension) and it gets successfully played from the File Browser with dev build e5c65a0039-240420.  To add to my embarrassment (and your amusement, I hope), here is the filename:

2-01 Adam_ Giselle, Act 2 - Introduction, halte des chasseurs et apparition des feux follets (The huntsmen rest and Will-o'the-Wisps appear).m4a

But the full pathname is "only" 224 chars (not that that reduces my embarrassment...).

I'm not yet sure whether or not this is even the longest filename in my library.

Is there a therapist for this kind of problem...?