[PROBLEM] Changes in JS

[Nutul]

You should be able to upload and attach a zip file but if not then upload it to a cloud drive and post a download link.

If the changes are relatively straight forward I might be able to slip them into the code b4 releasing 8.1.0 later this month.

No way... it won't let me attach any file, neither plain cource code, nor tar.gz...

so, here you are:

https://drive.google.com/file/d/1iRVL7sr...sp=sharing



Cheers, Al.

[TheOldPresbyope]

@Nutul

Nice.

So the develop branch has tags for each release. Try git tag -l to see the list of tagged releases in the distro. In this case, we want to checkout the tag r802prod. (Tim and bitlab can correct me if I'm misremembering; it's been an age since I worked with the whole code base.)

I did this and overlaid it with your files. I built from the result ala the Gulp development document. (Did I mention I haven't done this in an age? I ran into a little issue of my own which was causing nginx to throw a 403 error when I tried to access the resulting moOdeUI. Sigh. Managed to hack my way out of that.)

I don't use whole-album files with associated cuesheets so I had to create a test FLAC file + cue file + Folder.jpg (no embedded coverart).

In quick testing with just this album this evening, I can repro many of your results but I don't see coverart displayed everywhere I expect to, notably in Folder view or Album view (but I do see it in several places). Copying over the Folder.jpg file to cover.jpg and updating didn't make a difference.

No time to do more tonight.

Any thoughts?

Regards,
Kent

[Nutul]

@Nutul

Nice.

So the develop branch has tags for each release. Try git tag -l to see the list of tagged releases in the distro. In this case, we want to checkout the tag r802prod. (Tim and bitlab can correct me if I'm misremembering; it's been an age since I worked with the whole code base.)

I did this and overlaid it with your files. I built from the result ala the Gulp development document. (Did I mention I haven't done this in an age? I ran into a little issue of my own which was causing nginx to throw a 403 error when I tried to access the resulting moOdeUI. Sigh. Managed to hack my way out of that.)

I don't use whole-album files with associated cuesheets so I had to create a test FLAC file + cue file + Folder.jpg (no embedded coverart).

In quick testing with just this album this evening, I can repro many of your results but I don't see coverart displayed everywhere I expect to, notably in Folder view or Album view (but I do see it in several places). Copying over the Folder.jpg file to cover.jpg and updating didn't make a difference.

No time to do more tonight.

Any thoughts?

Regards,
Kent

Thanks for the help,

as for album art showing up somewhere but not everywhere... it could be you have set as priority to check for embedded art in the file?
In my collection I do not see the album art in the tag view only if I do not have the folder.jpg for the relevant album and I have Folder Image set as priority.

Just one hour ago I finished testing my whole collection of 268 albums, and not a single miss...

Maybe you can send me the FLAC + CUE + FOLDER.JPG?


Cheers, Al.

[TheOldPresbyope]

@Nutul

Ah, sorry Al.

Apparently if the following three facts are true (or maybe even just one or two) then the ability to report logically should be considered suspect:

• the reporter in question is an old man
  
• it's well past sundown
  
• at least one glass of wine has been consumed
  

It turns out I had mixed up the test albums I'd created. 

Long ago I ripped my entire CD collection to directories containing track-per-file FLACs. 

For my test of your code I used CueTools to create a new directory for each of several of the existing CD rips. In each case, CueTools created an album-per-file FLAC and its associated CUE file. In one case, I embedded the album coverart in the album-per-file FLAC and did not include a separate folder.jpg file in the target directory. In the other case, I did not embed the coverart but did include a separate folder.jpg file.

So, everything works as advertised in the case of an album-per-file FLAC with no embedded coverart + CUE file + folder.jpg file. For example, the album coverart image is displayed in the playback panel as each track is played and all the thumbnail displays are correct.

Not so in the case of an album-per-file FLAC with embedded coverart + CUE file and no folder.jpg file. The thumbnail displays are correct but the default cover ("images/default-cover-v6-l.svg") is displayed in place of the album coverart.

Changing the cover search priority has no effect.

It appears coverart.php is being passed a coverurl value based on the CUE file [1] and not the FLAC file. I haven't tried to read the PHP code involved but I'm supposing that if it fails to extract an image then it fails back on the separate image file if it exists, else the default cover image gets used.

To test this hypothesis, I simply added a folder.jpg file to the directory containing the album-per-file FLAC with no embedded coverart. Presto Chango, I now get coverart displayed for this case.

If my supposition is incorrect, then perhaps I somehow screwed up installing your code.

Regards,
Kent

[1] example for a directory which happens to be on a USB thumbdrive:  USB/RALLY8GB/Music/Green Day/Warning_/Green Day - Warning_.cue/track0001

[Nutul]

@TheOldPresbyope

(...)

Not so in the case of an album-per-file FLAC with embedded coverart + CUE file and no folder.jpg file. The thumbnail displays are correct but the default cover ("images/default-cover-v6-l.svg") is displayed in place of the album coverart.

Changing the cover search priority has no effect.

It appears coverart.php is being passed a coverurl value based on the CUE file [1] and not the FLAC file. I haven't tried to read the PHP code involved but I'm supposing that if it fails to extract an image then it fails back on the separate image file if it exists, else the default cover image gets used.

To test this hypothesis, I simply added a folder.jpg file to the directory containing the album-per-file FLAC with no embedded coverart. Presto Chango, I now get coverart displayed for this case.

Well, the embedded cover art is extracted ONLY from flac/mp3 and the like (actual audio files with an image-tag), CUEs don't have such a thing, so they are "parsed" for cover art (but there is no case for "cue"), but revert to the "folder.jpg". If that is not found, of course, the default cover art is returned by the PHP code.

One possible solution (but this will be consistent only for CUEs that do not contain multiple audio-files, possibly each with different cover art..):
Write a CUE parser, if one isn't already out there... replace the received path "/some/path/to/file.cue" with "/some/path/to/file.<ext>", and from here proceed with album-art extracting code... not trivial, though, I still prefer to have the "folder.jpg" file in the directory where flac + cue are.
Also, this would return the album-art of the first audio-file in the cue (if multi-artist), and this could be nonsense... and to check for only one FILE entry in the cue could be overkill...

But nevertheless, if you consider it a nice improvement about the CUE thing, I'll be happy to implement it...

If my supposition is incorrect, then perhaps I somehow screwed up installing your code.

Regards,
Kent

[1] example for a directory which happens to be on a USB thumbdrive:  USB/RALLY8GB/Music/Green Day/Warning_/Green Day - Warning_.cue/track0001

As I said, this is the expected behavior, as of now.

Your example file is the de-facto syntax that the cover-art extractor is given in case of single tracks played out of a CUE.

What my code does is the following:

get pathinfo(path, PATHINFO_BASENAME), and see if its first 5 characters are "track"; if so, get pathinfo(pathinfo(path, PATHINFO_DIRNAME), EXTENSION), and if this is "cue", then get its containing directory => and this will find out folder.jpg or the default cover, if missing.

in your example above:
pathinfo(path, PATHINFO_BASENAME) => track0001 => substr(0, 5) = "track" TRUE
pathinfo(pathinfo(path, PATHINFO_DIRNAME), EXTENSION) = "cue" TRUE

thus returning "USB/RALLY8GB/Music/Green Day/Warning_"

Nothing fancy, all in all it was you who said that CUEs are both files AND (virtual) directories... and here they behave as if they were a directory containing the single tracks. ;-)

Thank you for your time and observations, that keeps me motivated.

Let me know your thoughts, anyway.

Cheers, Al.

[TheOldPresbyope]

This is an academic issue for me since I don't use album-per-file rips. Nevertheless, if moOde is to support them, I believe it should also support the perfectly legit case of coverart embedded in the file.

AFAIK, a CUE file does not have to have the same basename as the music file it applies to or even be in the same directory but AFAIK the metadata in a CUE file always names the music file it applies to. For one of my example files,

Code:

REM COMMENT "CUETools generated dummy CUE sheet"
PERFORMER "Green Day"
TITLE "Warning:"
REM DISCNUMBER 1
REM TOTALDISCS 1
REM GENRE "Pop Rock"
FILE "Green Day - Warning_.flac" WAVE
 TRACK 01 AUDIO
   PERFORMER "Green Day"
   TITLE "Warning"
   INDEX 01 00:00:00
  TRACK...

This would seem to make it reasonably straightforward to deal with the indirection involved.

Regards,
Kent

[Tim Curtis]

We weren't able to slip in cue improvements for upcoming r810 but it's on the TODO list for r820 (Q3). We should be able to fix the cover art issues whether embedded or not, and for sure reference @Nutul code :-)

[Nutul]

We weren't able to slip in cue improvements for upcoming r810 but it's on the TODO list for r820 (Q3). We should be able to fix the cover art issues whether embedded or not, and for sure reference @Nutul code :-)

Hi Tim,

as soon as I can get my hands on the 8.1.0 baseline, I'll have a more structured approach at the conceptual changes needed for consistent CUE handling.
There is a nice thing KODI does, for instance, when dealing with CUE files: it actually treats them if they were directories. I'd like to achieve this in moOde too... ;-)

But first things first:
1. fix elegantly the issues with the cover art, having a consistent way of retrieving the image to be shown (still asking it on a CUE will only, and always, return the folder.jpg in the folder itself, instead of, for instance, looking inside the pointed audio file inside it. This will render the CUE files on-par with the physical directories (even though the dirs have some bugs, which I'll fix, too in due time)

For the time being, as soon as it is available, I'll just bring my changes onto the 8.1.0 locally, as I already can't imagine using moOde without them ;-)


It's a pleasure to have the possibility to contribute to this piece of art, you can count on me. Keep in touch.
Cheers, Al.