Long titles cut off in AzuraCast

[Moonbase59]

Installation Method

Docker Installation

AzuraCast Release Channel

Rolling Release Channel

Current AzuraCast Version

Rolling Release #1ea88fe (2023-10-14 0:27)

What happened?

Long titles are cut off in both media display and metadata editor. Long titles (even longer than mine) are typical in classical music, and apparently also with some other albums out in the wild.

Title 3 on Van der Graaf Generator’s album Pawn Hearts is called

A Plague of Lighthouse Keepers: A) Eyewitness - B) Pictures/Lighthouse - C) Eyewitness - D) S.H.M. - E) Presence of the Light - F) Kosmos Tours - G) (Custard's) Last Stand - H) The Clot Thickens - I) Lands End (Sineline) - J) We Go Now

for instance. It is cut off at … F) Kosmos Tours - G) ( in AzuraCast.

Maybe another assumption about field lengths in the database structure?

All my other tools worked with this, otherwise it wouldn’t be in the database.

If you let me know what your DB field length is for title, I could quickly make a search in Quod Libet to find how many (normal, mostly Rock/Pop) titles I have that are longer.

Of course I do see the problem when using databases with a fixed field length vs. the idea of "let a string be a string until a zero (or double zero) byte comes along" we have in C and most Linux tools, making multi-gigabyte strings possible which would never fit in a "normal" fixed-field-type database…

Then again, this might be one to tackle. Long titles seem to appear more often than I thought.

Anyway, if using something like mySQL or mariaDB, we can always use long VARCHAR fields—they go up to 64K in length. Not speaking of LONGTEXT, which handles 4GB max. The database will actually only use the extra space when needed, so staying efficient is no problem. (Many people still think in the old "fixed field width" terms and assume VARCHAR will always use the defined length, which is not true. The max. number as in VARCHAR(512) is just a capping, where it will truncate.)

The real culprit is indexing. You get rather inefficient when using long VARCHARs as an INDEX, but I don’t assume the title tag is used as an INDEX somewhere?

Relevant log output

No response

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Moonbase59]

NOT stale! Still happens in Rolling Release #f9f2530 (2023-12-11 17:19).

[BusterNeece]

@Moonbase59 Looking into it, title/artist/etc are 150 characters, and the combined "Text" is 303 (to allow for " - "). And they are indeed indexed for the search we do on the media manager page.

[Moonbase59]

My collection is rather "normal", mainly Rock & Pop, on a quick check I only found 19 Songs exceeding 150 characters title length, and 1 exceeding 150 characters artist name length.

This will be drastically different on classical music collections (often has collection names like "Köchelverzeichnis op. xxx part 1: yyy, part 2: zzz" and similar) and electronic dance music—I see things like "Somebody vs. Someone Else feat. Artist and Another Artist (remixer remix)" ever more often.

I wonder if it might be okay to increase title and artist to a VARCHAR(255) and the total text length to 512, or something on these lines? Happy to do DB speed tests on my 160,000 song collection if you let me know how and what to test.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Moonbase59]

Leave open in case it will eventually been fixed/enhanced.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.