.cue files not being handled by 7.7

[kjg]

I upgraded to 7.7 (on OS X Lion, and on Windows 7) and find that the
server no longer recognizes my single album FLAC+cue files. I have a few
hundred of these and none are being recognized by the server. Browsing
through the library shows the album, but the entry lists its contents as
empty. Navigating to the directory via the Music Folder shows the files,
but provides no controls for accessing them. I rolled back to 7.6 and
the problem was still there on OS X, but not on Windows. Rolling back to
7.5 on OS X seems to work fine.

Has anyone else seen this behavior with single album FLAC files using 7.7?

Thanks,
Ken

[chill]

Hi Ken

In preparation for installing Lion in the next few days, I finally got around to installing 7.7 last night (over 7.5.something), on a Mac Mini running OS X 10.6.8, and was pleasantly surprised how smoothly it went. Most of my rips are FLAC+CUE, and I didn't encounter any problems.

Do you perhaps have tags in your FLAC files, in addition to the information in the CUE files? Did you notice any problems in the database scan?

Chris

[Mnyb]

Cue+ file is broken in the browse "music folder" function, but should work fine in the standard menus artits albums genre, search and search.


http://bugs.slimdevices.com/show_bug.cgi?id=17404

is it case sensitive on linux it has always been case sensitive, but how does it work on OSX and modern windows ? Example on my linux server a cue sheet refering to file foo.flac would not work if the file name is Foo.flac

[chill]

...but how does it work on OSX...

Sorry - not sure, all my CUE files seem to point to the correct (case sensitive) FLAC files.

But I knew I shouldn't have opened my big mouth on this subject - it felt like I was tempting fate even while I was writing my first reply! This evening I ripped a couple of new CDs to FLAC+CUE and did a rescan ('Look for new and changed media files' only), and then browsing by Artist to the new albums all I saw was the single FLAC file (which was playable) - the CUE file information didn't seem to have made its way into the database.

A rescan with 'Clear library and rescan everything' fixed it though. Not the same problem as the OP (probably), but it seems related. I'll see if its reproducible with another new rip later this evening.

[kjg]

On 11/15/11 8:54 AM, Mnyb wrote:

> is it case sensitive on linux it has always been case sensitive, but
> how does it work on OSX and modern windows ? Example on my linux
> server a cue sheet refering to file foo.flac would not work if the file
> name is Foo.flac

Hmm. This may be the issue. The .cue files were generated on a Windows
system and are now being used on OS X. I did, however, experience the
same problem on Windows 7 using 7.7.

I'll check the .cue files, adjust the case if needed, and try again to
see if this is the issue.

- Ken

[chill]

Cue+ file is broken in the browse "music folder" function, but should work fine in the standard menus artits albums genre, search and search.

After further testing I think this is the root of the problem that I was experiencing (CUE file information not updating with a 'new and changed' scan). I think that by navigating into the folder where the FLAC+CUE album is stored, the database attempts to update but doesn't do so correctly, according to the bug that Mnyb highlighted above. However, that particular file then no longer shows up as new or changed, so a quick database rescan doesn't look at it again to parse the CUE file correctly.

So provided I don't browse my Music Folder to the new files before doing a 'new and changed' scan, new files should be handled correctly.

[kjg]

On 11/15/11 8:54 AM, Mnyb wrote:
>
> Cue+ file is broken in the browse "music folder" function, but should
> work fine in the standard menus artits albums genre, search and
> search.
>
>
> http://bugs.slimdevices.com/show_bug.cgi?id=17404
>
> is it case sensitive on linux it has always been case sensitive, but
> how does it work on OSX and modern windows ? Example on my linux
> server a cue sheet refering to file foo.flac would not work if the file
> name is Foo.flac

I think my problem exists regardless of how the server sees the flac+cue
files. I reinstalled 7.7 on OS X (Lion) and ran a full scan. The file
names in the .cue files are correct and the log indicates that the .cue
file is recognized and is able to find the flac file. All looks fine in
the logs, except that when I navigate to the album in the library, it
shows the artwork, the album duration, and a string that says "Empty",
with no tracks.

A snippet of the log is:

[11-11-17 22:07:39.5544] Slim::Utils::Scanner::Local::new (811) Handling new playlist file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/Albert%20Ayler%20-%20Spirits%20Rejoice.cue
[11-11-17 22:07:39.5567] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1083) Will scan file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/Albert%20Ayler%20-%20Spirits%20Rejoice.cue, base: file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice
[11-11-17 22:07:39.6925] Slim::Music::Artwork::findStandaloneArtwork (153) Using /Volumes/Data 2/Music/Music For Server/FLAC/Albert Ayler/Spirits Rejoice/folder.jpg
[11-11-17 22:07:39.7540] Slim::Music::Artwork::findStandaloneArtwork (153) Using /Volumes/Data 2/Music/Music For Server/FLAC/Albert Ayler/Spirits Rejoice/folder.jpg
[11-11-17 22:07:39.7925] Slim::Music::Artwork::findStandaloneArtwork (153) Using /Volumes/Data 2/Music/Music For Server/FLAC/Albert Ayler/Spirits Rejoice/folder.jpg
[11-11-17 22:07:39.8253] Slim::Music::Artwork::findStandaloneArtwork (153) Using /Volumes/Data 2/Music/Music For Server/FLAC/Albert Ayler/Spirits Rejoice/folder.jpg
[11-11-17 22:07:39.8309] Slim::Music::Artwork::findStandaloneArtwork (153) Using /Volumes/Data 2/Music/Music For Server/FLAC/Albert Ayler/Spirits Rejoice/folder.jpg
[11-11-17 22:07:39.9252] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1159) Found 5 items in playlist:
[11-11-17 22:07:39.9254] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1163) file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac#0-699.76
[11-11-17 22:07:39.9256] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1163) file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac#699.76-832.333333333333
[11-11-17 22:07:39.9257] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1163) file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac#832.3333333333 33-1312.29333333333
[11-11-17 22:07:39.9259] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1163) file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac#1312.293333333 33-1640.82666666667
[11-11-17 22:07:39.9260] Slim::Utils::Scanner::Local::scanPlaylistFileHandl e (1163) file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac#1640.826666666 67-1975.2
[11-11-17 22:07:39.9266] Slim::Utils::SQLiteHelper::updateProgress (398) Notify to server: [
"progress:1321596314.64765||importer||/Volumes/Data 2/Music/Music For Server|directory_new||7062||27803||",
]
[11-11-17 22:07:39.9293] Slim::Utils::SQLiteHelper::updateProgress (422) Notify to server OK
[11-11-17 22:07:39.9296] Slim::Utils::Scanner::Local::new (773) Handling new audio track file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Albert%20Ayler/Spirits%20Rejoice/singlefile_2006_9_19_20h11m42s.flac

Everything seems fine to my untrained eye, but maybe someone with a
better understanding of what's happening inside would be able to see
something in this. As I mentioned earlier, this process worked perfectly
well in 7.5.

- Ken

[Mnyb]

And you are browsing it by going artist or album menu NOT via "music folder" :-/
Then it looks like yet another bug .

[kjg]

On 11/17/11 10:42 PM, Mnyb wrote:
>
> And you are browsing it by going *artist* or *album* menu NOT via "music
> folder" :-/
> Then it looks like yet another bug .

I'm using the Artist / Album route, not Music Folder. If I navigate
using the Music Folder, I can see the flac and cue files, but they're
not links and I can't click on them. I do get the "add to favorites"
icon, and can add the cue file to the Favorites list. Under that I'm
able to click the link, but I end up with this error:

There was an error loading the remote feed for : (Cannot request
non-HTTP URL
file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Alison%20Krauss%20+%20Union%20Station/Alison%20Krauss%20+%20Union%20Station%20Live%20(Di sc%201%20of%202)/Alison%20Krauss%20And%20Union%20Station%20-%20Live%20(Disc%201%20of%202).cue)

I should pass all this info along to Logitech as a bug. All this seems
somewhat worse than the bug you posted.

- Ken

[Mnyb]

On 11/17/11 10:42 PM, Mnyb wrote:
>
> And you are browsing it by going *artist* or *album* menu NOT via "music
> folder" :-/
> Then it looks like yet another bug .

I'm using the Artist / Album route, not Music Folder. If I navigate
using the Music Folder, I can see the flac and cue files, but they're
not links and I can't click on them. I do get the "add to favorites"
icon, and can add the cue file to the Favorites list. Under that I'm
able to click the link, but I end up with this error:

There was an error loading the remote feed for : (Cannot request
non-HTTP URL
file:///Volumes/Data%202/Music/Music%20For%20Server/FLAC/Alison%20Krauss%20+%20Union%20Station/Alison%20Krauss%20+%20Union%20Station%20Live%20(Di sc%201%20of%202)/Alison%20Krauss%20And%20Union%20Station%20-%20Live%20(Disc%201%20of%202).cue)

I should pass all this info along to Logitech as a bug. All this seems
somewhat worse than the bug you posted.

- Ken

yes this is worse file bug.