I have removed my folder, unzipped the TestCUE.zip and cleared the tags of the library and regenerated the library. Same problem.
Also tested with the "file" command and I get the same result than TheOldPresbyope, i.e. WishYouWereHere.cue: ASCII text, with CRLF line terminators.
There must be something else that prevents the CUE files from working correctly in my system (in case you wonder, I don't have the Toggle "Ignore CUE files" enabled in the library configuration, it displays Off).
I will try to find the MPD database and library tag cache to see what is created.
07-25-2024, 10:42 PM (This post was last modified: 07-25-2024, 10:53 PM by jcucurull.)
(07-25-2024, 10:36 PM)jcucurull Wrote: I have removed my folder, unzipped the TestCUE.zip and cleared the tags of the library and regenerated the library. Same problem.
Also tested with the "file" command and I get the same result than TheOldPresbyope, i.e. WishYouWereHere.cue: ASCII text, with CRLF line terminators.
There must be something else that prevents the CUE files from working correctly in my system (in case you wonder, I don't have the Toggle "Ignore CUE files" enabled in the library configuration, it displays Off).
I will try to find the MPD database and library tag cache to see what is created.
If I search inside the MPD database, it seems the CUE has been read and interpreted, because it segments the album in songs:
Code:
# mpc listall
...
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0001
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0002
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0003
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0004
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0005
...
Also, if I search for Pink Floyd songs, it lists the ones of this album:
Code:
# mpc search '((artist == "Pink Floyd"))'
...
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0001
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0002
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0003
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0004
USB/Storage/Musica/Masters/Biblioteca-Lossy/Pink Floyd/Wish you were here/WishYouWereHere.cue/track0005
...
If I search the albums in the DB, it also shows this album:
Code:
# mpc list album
...
Wish You Were Here
...
So it seems the database and tags are correctly generated. Notice the "..." were added manually by me, because more results where shown a part from the ones of this album.
@Tim Curtis @TheOldPresbyope Given that the local MPD database seems fine, could it be that what is sent to the browser (a JSON, right?) is incorrectly build?
I don't know how this works internally, but I guess a JSON is build to load the library in the frontend. If this JSON had some issue, e.g. due to an unsupported character, maybe might be presenting these kind of issues in frontend side. Is there a manner to easily see the information sent to the browser? Or is not sent as a single piece of data?
(07-29-2024, 12:35 PM)jcucurull Wrote: @Tim Curtis @TheOldPresbyope Given that the local MPD database seems fine, could it be that what is sent to the browser (a JSON, right?) is incorrectly build?
I don't know how this works internally, but I guess a JSON is build to load the library in the frontend. If this JSON had some issue, e.g. due to an unsupported character, maybe might be presenting these kind of issues in frontend side. Is there a manner to easily see the information sent to the browser? Or is not sent as a single piece of data?
Best,
Jordi.
The library cache JSON files are in /var/local/www/ and are named libcache_*.json
(07-29-2024, 12:35 PM)jcucurull Wrote: @Tim Curtis @TheOldPresbyope Given that the local MPD database seems fine, could it be that what is sent to the browser (a JSON, right?) is incorrectly build?
I don't know how this works internally, but I guess a JSON is build to load the library in the frontend. If this JSON had some issue, e.g. due to an unsupported character, maybe might be presenting these kind of issues in frontend side. Is there a manner to easily see the information sent to the browser? Or is not sent as a single piece of data?
Best,
Jordi.
I think this is grasping at straws but that's just me. Since I don't have the problem you describe with any personal or user-provided test albums in my collection and I can't repro it with the file you provided I can't really contribute anything more.
08-02-2024, 07:23 PM (This post was last modified: 08-02-2024, 07:26 PM by jcucurull.)
(07-29-2024, 02:05 PM)Tim Curtis Wrote:
(07-29-2024, 12:35 PM)jcucurull Wrote: @Tim Curtis @TheOldPresbyope Given that the local MPD database seems fine, could it be that what is sent to the browser (a JSON, right?) is incorrectly build?
I don't know how this works internally, but I guess a JSON is build to load the library in the frontend. If this JSON had some issue, e.g. due to an unsupported character, maybe might be presenting these kind of issues in frontend side. Is there a manner to easily see the information sent to the browser? Or is not sent as a single piece of data?
Best,
Jordi.
The library cache JSON files are in /var/local/www/ and are named libcache_*.json
The library in JSON seems fine, the songs and all the associated metadata appears and it seems similar to the data of the other songs in other formats (see attachment). What I have seen is that I have only populated the libcache_all.json, the other json files have 0 bytes.
So probably the issue I am facing is a frontend issue when processing this file in the browser. Is this file sent as a whole to the browser? Or is the file used by the server and the information processed and sent in pieces to the browser as needed?
ANSWER: I answer myself, using the development tools of the browser I have seen that the whole JSON file is sent. So I will research from there to see what is going on with my frontend.
After taking a bit of time with this debugging using the developer tools of the browser, I have found the origin of my issue and why @Tim Curtis and @TheOldPresbyope could not reproduce it.
The issue only happens when the library is set to compute the Album Key as Folder Path, which is how I have it configured. If the Album Key is computed as the default Album#Artist, it works correctly. Thus, the issue only affects the computation of the Album Key as Folder Path I guess. I explain the bug in the text below.
The bug explained
Debugging the code with the browser, I realised about a difference in the regular albums (several FLAC files) and the ones based on a CUE (APE+CUE).
As I observed, when an album is clicked the method "keyAlbum(obj)" is called to compute the identifier of the album. This identifier is laterly used in the function "filterSongs()" to filter from a list of all the songs of the library only the ones that match the album identifier computer in the former one.
This album identifier looks like the string of the album name concatenated with an MD5 and and additional album ID (I guess from the database in case it is defined). The matter is that in a regular album the key computed matches the one within the object "object.key" that represents the album. But in the case of my CUE+APE albums, it does not. See an example (first album is a regular one, second is a CUE+APE):
I have seen this MD5 in my case if just copied from the name of the image that represents the album, specifically in this code (in "scripts-library.js") it uses the second condictional:
Code:
if (miscLibOptions[2] == 'Yes') { // Folder path albumkey
// Use folder path
if (typeof(obj.file) != 'undefined') {
var md5 = $.md5(obj.file.substring(0,obj.file.lastIndexOf('/')));
}
else if (typeof(obj.imgurl) != 'undefined') {
var md5 = obj.imgurl.substring(obj.imgurl.lastIndexOf('/') + 1, obj.imgurl.indexOf('.jpg'));
}
return obj.album.toLowerCase() + '@' + md5 + '@' + obj.mb_albumid;
}
And this MD5 does not match the existing one in the field "key" of this same album object (see attached images for two albums, one regular one CUE+APE). Thus, the manner how the key is initially computed and populated in the album object, and how it is computed when the album is filtered, is different and produces the error. What I don't know is why this only happens with the CUE+APE case and not with the non CUE cases.
The issue is being caused by a line of old code that was never updated to handle cue files using the super nice CUE support that @Nutul developed.
In fact when using Folder Path as the album key all cue files fail to display tracks because the wrong parent dir is being used to generate the hash for the album key. This causes filteredSongs to be empty and thus the code at line 858 blows up.
Code:
file: "USB/VFAT64/Test_mixed/Jcucurull/APE/Wish you were here/WishYouWereHere.cue/track0001"
# Old code
var md5 = $.md5(obj.file.substring(0,obj.file.lastIndexOf('/')));
# Console demo
$.md5("USB/VFAT64/Test_mixed/Jcucurull/APE/Wish you were here/WishYouWereHere.cue");
e43d5ed42ee8df48e01911713ea701ad
# New code
var md5 = $.md5(getParentDirectory(obj.file));
# Console demo
$.md5("USB/VFAT64/Test_mixed/Jcucurull/APE/Wish you were here");
14507c9ac0b6a8198e06f12292e7235a