PDA

View Full Version : cover column filled in default skin when viewing current playlist ?



erland
2007-11-08, 11:31
In the tracks table there is a cover column. During scanning the first track of each album is filled with a value in the cover column that points to the cover.jpg file.

When using the classic or fishbone skins the other tracks doesn't seem to get a value in the cover column. However, the strange thing is that if you use the default skin and add a track to the current playlist it will fill that tracks cover column.

I think the reason the cover column is filled in the default skin is that the current playlist in the default skin displays cover art for each track, this isn't the case in fishbone and classic skins.

If the cover column is really needed for all tracks on the album, wouldn't it be better to fill it for all tracks during the scanning process. Or is there some reason that we don't want to do it during the scanning ?

I haven't seen any problem with this behaviour, but from a database consistency point of view it would feel better if the cover column was filled on all tracks during the scanning process.

JJZolx
2007-11-08, 18:24
If the cover column is really needed for all tracks on the album, wouldn't it be better to fill it for all tracks during the scanning process. Or is there some reason that we don't want to do it during the scanning ?

I haven't seen any problem with this behaviour, but from a database consistency point of view it would feel better if the cover column was filled on all tracks during the scanning process.
But from a database perspective it's also desirable to avoid storing the exact same bit of data in every track within the album when all tracks use the same cover artwork file.

The trouble with the implementation is that resolving the artwork must be rather roundabout. If cover is NULL, you go query the album record, then you go back and get the track record that has the artwork reference.

I think a cleaner and easier to use design (easier because it would then be a simple join rather than multiple queries to get artwork) would be to have a separate artwork table, with foreign keys into that table from both the tracks and albums table. If desired, this design could also be easily extended some day for the many requests for SlimServer to be able to catalog and display all album art (image files), rather than just covers.

erland
2007-11-08, 21:32
I think a cleaner and easier to use design (easier because it would then be a simple join rather than multiple queries to get artwork) would be to have a separate artwork table, with foreign keys into that table from both the tracks and albums table.
Even though I agree with you, I'm not really worried about the fact that it is stored in the tracks table at the moment.

The thing that makes it strange is that viewing the current playlist in a specific skin causes additional information to be filled in the database that isn't filled in during the scanning process. If this information is required, my feeling is that it should be filled in by the scanning process and not the first time a track is viewed with cover art in a specific skin

JJZolx
2007-11-09, 11:53
Even though I agree with you, I'm not really worried about the fact that it is stored in the tracks table at the moment.

The thing that makes it strange is that viewing the current playlist in a specific skin causes additional information to be filled in the database that isn't filled in during the scanning process. If this information is required, my feeling is that it should be filled in by the scanning process and not the first time a track is viewed with cover art in a specific skin

Ok, yeah, I'm seeing the same thing. This shouldn't be working like this. Normally the NULL cover columns remain NULL and the artwork is resolved through the album and the one track record containing the artwork path.

- In the new Default, when you add tracks to the playlist with covers turned on, all track records get updated and cover is populated in each track.

- In Default, Fishbone and Classic skins, when the track is _played_, cover gets populated. Default and Fishbone show a cover in the status pane, but Classic doesn't.

- It also happens upon viewing the song info page for a track in any skin.

- From what I can see in SlimServer 6.5, the track is never updated and cover remains NULL.

It definitely seems that when SC7 tries to find the covers for tracks, something must be broken. If the tracks are also being rescanned when this happens, this seems like a fairly serious bug. That's a lot of unnecessary rescanning of tracks.

kdf
2007-11-09, 12:49
A cover art request is not the same as a tag scan. It takes into account all of the currently supported methods of getting artwork, while trying to avoid any unnecessary extra scanning. As for why it's done on the fly, it's to reduce post scan tasks, take care of live data changes as much as possible and also cover a far too flexible feature set (mainly the infoformat-based artwork filenaming).

If you'd like to take on a re-engineering of the artwork API, you are most welcome. A great number of people will be anxiously awaiting your patches.

-kdf

Dan Sully
2007-11-09, 12:56
* kdf shaped the electrons to say...

>If you'd like to take on a re-engineering of the artwork API, you are
>most welcome. A great number of people will be anxiously awaiting your
>patches.

I know I have. For a few years now.

-D
--
<dsully> please describe web 2.0 to me in 2 sentences or less.
<jwb> you make all the content. they keep all the revenue.

JJZolx
2007-11-09, 13:19
A cover art request is not the same as a tag scan.

I said it may be rescanning the files. I'll take a look at it later to see whether that's happening, or if it's merely updating the cover column.


As for why it's done on the fly, it's to reduce post scan tasks, take care of live data changes as much as possible and also cover a far too flexible feature set (mainly the infoformat-based artwork filenaming).

I realize why it's done like this. What we're saying is that there appears to be something wrong in SC7 when retrieving artwork for these tracks where cover is NULL. There should be no need to update the record unless something has changed since 6.5 in the way covers are resolved for tracks. If SC7 does work differently, and requires each record to include the full path to the artwork file, then as erland points out, this should be done during the library scan.

erland
2007-11-09, 23:11
A cover art request is not the same as a tag scan. It takes into account all of the currently supported methods of getting artwork, while trying to avoid any unnecessary extra scanning. As for why it's done on the fly, it's to reduce post scan tasks, take care of live data changes as much as possible and also cover a far too flexible feature set (mainly the infoformat-based artwork filenaming).

Thanks, if it is done this way by design it should be fine.
I just wasn't sure this was the case when it behaved differently compared to what I've seen in 6.5.

Just out of curiosity, will the cover column be overwritten even if it contains a value ?

kdf
2007-11-09, 23:24
On 9-Nov-07, at 10:11 PM, erland wrote:

>
> Just out of curiosity, will the cover column be overwritten even if it
> contains a value ?

for metadata art, if the track is detected as changed.

I believe it also rechecks the file for file artwork if the timestamp
shows as changed.

Some things have changed since 6.5. for example, if a thumbnail
hasn't been populated, then when a track
is loaded that has artwork, it will populate the album cover column.
If a track timestamp has changed, this is
updated now without affecting the album cover (thanks to a patch from
jim)
-kdf