Are there limits to numbers of albums that display under an artist in the Web interface or app?

[David Mednicoff]

Dear Brennan users

With almost 3300 CD's now ripped to my 2T B2, I have what seems to me a strange issue.

Most of my CD's are classical, and organize them by composer. That is, the composer is the "Artist" for my file organization, and include the main performers in the album title information. 

I have a good number of CD's that have a range of composers that I file under the artist "Mixed Composers." Within that artist name, not all of the albums display on the web interface, which makes it hard to access and play them. I have run Scan Disk a lot (most days now), and the issue has not corrected.

Is there a limit that I didn't see anywhere about how many CD's can be listed under an artist? If so, is there some easy way to find all of the CD's (they show up when I search for a particular one, but I don't have a hard copy of all of the CD's I own or have ripped)? If not, does anyone have suggestions?

Thanks for any knowledge and suggestions on this.

Prof. David Mednicoff

P.S. For those of you who posted about my USB backup issue, indeed the problem appears to have been that I was using falsely labelled 2TB USB thumb drives. I bought a small Toshiba 2TB drive, and that worked well both for an initial backup and for a progressive backup update yesterday. Thanks for your help!

[Daniel Taylor]

Regarding not all of the albums for a given artist being viewable on the WebUI:  I have not encountered that situation yet.  I wonder if the number of albums is simply more than can be viewed in the window pane on the WebUI.  For the other panes, when the amount of information is too great to be displayed all at once, you must make use of the scroll bar.  On the WebUI, the scroll bars do not appear unless/until you move the mouse pointer over where they would be to the right of the column.  Try that in the album pane.

[David Mednicoff]

Thanks. I have been able to scroll with respect to other artists with a large number of CD's but not this one.

Indeed, in trying to check this I ran into an additional more serious problem. When I try to look at all of the CD's under a different artist, where I know there are many ripped CD's, it doesn't work at all and instead displays a different artist's name repeatedly. This is obvious some sort of data glitch. I have tried scanning the disk to refresh the music index several times without success. Does anyone have any suggestions of fixes? Thanks again.

David

[Daniel Taylor]

Are the album names quite long?  There is a limit of 170 characters.  If that is ever exceeded, the results can be wildly puzzling.

[David Mednicoff]

That's good to know about the album names, but I don't think the ones that don't show in the Web interface are more than 170 characters.

[Mark Fishman]

No, no: when you have ANY that are more than 170 characters, strange things happen and it might be impossible to list any or all albums around or after that entry. It's not just that long names are suppressed or truncated, but that they completely bollix the display.

By the way, Martin Brennan has reminded us that Unicode characters can occupy more than one byte each, so the "170 limit" is probably shorter than that if you use acented or non-English characters.

[PMB]

Hi All,

I wonder if there is a title longer than 170 characters and causing a problem with the web UI, would NAS still display all of the Albums and titles - As I understand it it's a web UI problem...?

Paul

Brennan Support.

[Mark Fishman]

Paul,

Yes, it seems to be *at least* a Web UI problem -- but possibly also a problem on the front panel display (I don't think any one has tried that, as looking for albums under an artist that has many albums would be difficult at best using the frnt panel and remote).

See the messages surrounding https://groups.google.com/g/brennanb2/c/e_BUSkM1pvM/m/bREDSc_YAgAJ in another thread about this same issue (and the same people). David was able to see and shorten his longest filenames using NAS, and after a Scan Disk and reboot, the Web UI went back to behaving correctly.

The underlying filesystem, and Samba, and Windows, seem to be OK with the names; the problem is somewhere in the Brennan-specific software.

Cheers -- m.

[David Mednicoff]

Yes -- thanks to all who helped on this. Mark has correctly identified the issue, and all continues to work just fine for me now that I eliminated the CD titles over 170 characters.

[Peter Lowham]

Hi Paul,

I believe that the nearest filename limiting factor is in Windows FAT32, which has a maximum filename length of 255 characters.

Regards,

Peter.

[Mark Fishman]

As we have seen, though, Brennan-related problems begin to happen well before the underlying filesystem (or operating systems, Linux and Windows) might have trouble creating and displaying the filenames. In David's case, for example, he had a filename around 200+ characters: it was on the disk that way, as could be seen using NAS, so Linux, the Samba server process, and Windows (as a client) had no trouble with it.

Yet it thoroughly bollixed not only the display of albums, but also the Web UI association of other album names with their proper artists.

If there's a problem with long filenames, the software should behave more gracefully when it encounters them. One approach would be to truncate long names when they are encountered during a Scan Disk, Upload, or Import process. Another would be to flag them for user attention. There are undoubtedly other methods. For example, if I have a filename that is too long on a Windows system (local disk), Windows will complain if I try to change the name without also shortening it sufficiently, and some applications will simply not find such a file because internally they have truncated the name.

But things that should not happen are to scramble the display or crash.

[Peter Lowham]

Hi Mark,

Yes I agree with you on that.  The JB7 has an album name  limit of about 65 characters, but it will restore albums with names much longer than this.  However it just truncates the album name to 64 characters when it updates the album table and that's the end of the story.  It is simple but entirely effective.

Regards,

Peter.

[Daniel Taylor]

One problem with simple truncation is that the resulting character string may not be unique.  Then you are faced with the need for multiple folders or files with the same name, which of course cannot be allowed (at least not at the same directory level).  In the case where the user is entering the string within control by B2 software, he could be prompted to edit appropriately.  In other cases, there may be no alternative other than to truncate.

Allowing a character string to exceed the amount of space allotted for it can be catastrophic.  When there are more than 170 characters in a string, where do the excess characters go?  Unless the software prevents it, they overwrite adjacent areas in memory.  In some cases, that changes the names of other folders or tracks.  In extreme cases, that could overwrite executable code - which, when later is attempted to be executed, can cause outrageous results.

[Mark Fishman]

Don't ever tell anyone I said this, but: I actually think Microsoft's approach to avoiding name clashes works well. If you attempt to copy in a file whose name matches an existing name, you are asked whether to overwrite, skip, or keep both versions -- in which case Windows appends a version number in parentheses to the otherwise matching name. And if you remember MS-DOS 8.3 names, the "short" name that is created for files that have long names is the first 6 characters followed by ~1, or ~2, or ~3, and so on, to avoid collisions even in the first few characters.

Simple truncation, even with a collision-avoidance mechanism, will ano doubt annoy people who want to put every possible descriptor in thje filename, but IMHO is preferable to misbehavior with weird consequences.

One of the unspoken responsibilities of a system administrator, or a programmer, is to protect the system from unexpected behavior by users. I think this is one such opportunity.

[Daniel Taylor]

Bravo!

[Peter Lowham]

Hi Guys,

The JB7 method of processing potential duplicate folders is very simple; it just appends the new music tracks to the existing folder.

Note that the JB7 only has a single level folder which is the '<Artistname><3 space chars><Albumname>'.

For example, in one of my cases, the two folders in question were:

George Harrison   All Things Must Pass [30th Anniversary Edition] Disk 1          (this album had 14 tracks)
George Harrison   All Things Must Pass [30th Anniversary Edition] Disk 2          (this album had 14 tracks)

When I initially loaded these folders onto the JB7, I did my usual reconciliation checks and found only one folder which was named:

George Harrison   All Things Must Pass [30th Anniversary Edition      (so this was the truncation)

But when I checked this folder, it contained 28 music tracks, so no data was lost.

I rearranged the naming to move the unique identifier (CD 1 & CD 2) to be inside the 64 character limit as follows.

George Harrison   All Things Must Pass CD 1 [30th Anniversary Ed
George Harrison   All Things Must Pass CD 2 [30th Anniversary Ed

So the JB7 method is simple but effective.

Regards,

Peter.

[Mark Fishman]

That's fine for folders -- what happens if the combined folders (that were intended to be separate) will have tracks with the same names?

[Peter Lowham]

Hi Mark,

A good question and I don't yet know the answer to that.  In my example, the track names were unique so there wasn't a problem.  I suspect that the newer track file will overwrite the existing one but I will need to check this out, just out of interest.

Regards,

Peter.

[Daniel Taylor]

In Peter's example, the files were combined into the single folder that resulted from the automatic truncation.  Making two separate folders was done later by Peter, not the JB7.  If the B2 would make the folder names different automatically (as in the Microsoft example that Mark provided) the files would never have to compete with each other.

Consider the multi-disc set where each disc has the same name.  After the first disc is ripped, when the second disc is encountered, the duplicate name would be modified with "~2" or similar for a new folder, and the files for Disc2 would automatically go into a separate folder from Disc1.

[Daniel Taylor]

My example is incomplete.

In the case where folders with too-long names are encountered on the disc (probably after being added via NAS), the first folder would be truncated.  Subsequent folders with the same truncated part of the name would be modified with the "~2", "~3" etc.  If desired, the first folder that could be modified as well, to "~1".  In fact, the very fact that the name had to be truncated could result in the "~1" being substituted for the last two characters.

[fred.w....@gmail.com]

If you stand on the top of the hill and look at the problem from afar, then I at least come to the conclusion that identfying the contents of a file by/using the physical file name will inevitably lead to problems.

The solution is to make the files self describing, embedding their word names in them. This then seperates the file name regime used to physically store a file from the variations about how a file may be used or its contents identified.

Did I just describe the use of and case for metadata tags ? 😁 or perhaps also make a case for removing the need for traditional root/branch/and leaf file structures (to some extent in the user interface) 😁😁

Dear me I must be feeling naughty today!

Fred

[Mark Fishman]

Why, Mr Hopper, I do think you have invented metadata and the relational database!

I was trying to avoid that in order to focus on the problem -- corruption due to improper handling of names -- rather than propose a solution that still requires fixing the existing problem. Using tags would address the issue of how to store the information, but we still need to stop the crashes and squirrely behavior if someone uses a long name.