mherger wrote: 
> > Ok, it looks like it still requires a change to the audio files, such
> as
> > a timestamp change, before the new cover is picked up. But the new
> cover
> > is picked up correctly.
> 
> Ok, assuming the following, I think picking up changed artwork without 
> 
> touching the music files should work without major changes:
> 
> - we only deal with external artwork (otherwise the music file would be 
> 
> touched anyway)

Right.

> - we only deal with changes to the cover art file's content, not the  
> filename itself. If the artwork file is renamed (for whatever reason), 
> 
> this change will not be picked up and will result in a loss of the
> artwork  
> for that album.

For instance, if someone replaces a cover.jpg file with folder.jpg,
correct? I think that's fine.

Would it also be capable of finding a new cover where an album or track
had none previously? This is fairly important.

> How does that sound?

Good.

> 
> > In the database's tracks table, I see similar results as before. Each
> > track shows a different coverid, but the same cover.jpg path. I
> notice
> > that the album-level resized thumbnails and full sized cover
> reference
> > the coverid stored for the last track in the album.
> 
> I think I know where this comes from: sometimes we would write the same
> id  
> for all tracks of an album. And sometimes every track is handled  
> independently. Yes, it depends on how your scan is run (and there are  
> about three or four different ways... ouch!).

Yes, that's what I figured. When it happens, does it mean that each file
now has an individual full set of resized covers in the cache? Does a
new & changed scan cache resized covers, like a full scan, or do they
get resized only when requested?


------------------------------------------------------------------------
JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
View this thread: http://forums.slimdevices.com/showthread.php?t=100277

_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/beta

Reply via email to