Bug 4565 - Look for new or changed music does not pick up new art
: Look for new or changed music does not pick up new art
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.5.1
: PC Windows Server 2003
: P1 normal with 6 votes (vote)
: 7.6.0
Assigned To: Andy Grundman
: TinySC
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-04 18:37 UTC by Alex
Modified: 2011-04-28 09:05 UTC (History)
5 users (show)

See Also:
Category: Bug


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2006-12-04 18:37:31 UTC
If, for example, the files are changed from an mp3 format to flac, or the files are renamed to a different format, a "look for new or changed music" scan does not display the thumb view of the album in a browsing of albums by artist. A full rescan is required for the album thumb to be displayed in the album view of the artist.
Comment 1 Jim McAtee 2006-12-04 19:00:51 UTC
This is a duplicate of bug 2931 and/or bug 2116.
Comment 2 KDF 2006-12-04 23:17:44 UTC
not to mention bug 4130.  At all times, a full rescan has been the instruction for gathering a complete list of artwork.  Removing this requirement is an obvious goal, but one that has not been claimed as achieved.
Comment 3 Alex 2006-12-05 04:19:21 UTC
FYI - A full scan takes about 5 hours to perform on my system. During which time SBs become unresponsive and I cannot listen to any music effectively.
Comment 4 Chris Owens 2006-12-08 16:12:50 UTC
Alex, that might count as a separate bug *if* you are using Slimserver 6.5 or higher, which have the scanner as a separate process.  However you did not make a note of your Slimserver version.  If you are using an older version, you should try upgrading.
Comment 5 Alex 2006-12-08 18:11:43 UTC
Sorry for not specifying. I am using the nightly 6.5.1 release.
Comment 6 Chris Owens 2006-12-09 13:20:06 UTC
What kind of hardware are you running on?

As for the duplicate bugs, this bug IS a duplicate of those other bugs, but if one actually reads those other bugs, it should clearly be an enhancement request now that the split scanner is a reality (post-6.5.0) so  have changed the severity, milestone, and Summary to reflect that.
Comment 7 Mike Walsh 2009-04-08 01:04:44 UTC
this:

https://bugs-archive.lyrion.org/show_bug.cgi?id=9271

appears to be a dupe of this bug.  however it has good info in it.
Comment 8 Andy Grundman 2009-06-09 16:16:39 UTC
*** Bug 8387 has been marked as a duplicate of this bug. ***
Comment 9 Andy Grundman 2009-06-09 16:44:03 UTC
*** Bug 12017 has been marked as a duplicate of this bug. ***
Comment 10 Andy Grundman 2009-07-29 14:58:28 UTC
Moving 7.4 bugs to 8.0.
Comment 11 Till 2009-10-17 03:53:36 UTC
(In reply to comment #10)
> Moving 7.4 bugs to 8.0.

Excuse me !?!

This needs to be fixed (or this bug be closed and https://bugs-archive.lyrion.org/show_bug.cgi?id=13315 be fixed).

Fix it before 8.0. Period.
Comment 12 Chris Chatfield 2009-10-17 05:25:49 UTC
This bug has been an annoyance for users of the browser interface since forever now. For those who bought the duet controller, they must wonder why they wasted their money. This really needs to be fixed before the Squeezebox Touch is available to buy. It looks quite likely that full rescans on the Touch will take a very very long time. Logitech are going to face a torrent of vitriol if album art is not detected along with new music without having to do a full rescan.

This bug needs to be in the high priority group.
Comment 13 SVN Bot 2009-10-28 08:15:03 UTC
 == Auto-comment from SVN commit #29037 to the slim repo by andy ==
 == https://svn.slimdevices.com/slim?view=revision&revision=29037 ==

Fixed bug 4565 and probably others:
* Changed all artwork URLs to use a new coverid field, which is not based on the track ID but on the URL+mtime+filesize so any changes to one of these values will result in a new URL and correct artwork.
* Removed the findArtwork scan phase, artwork is now found during the main scan phase.
* Added a new precacheArtwork scan phase that should do a better job precaching everything that hasn't already been cached.
Comment 14 Philip Meyer 2009-11-01 04:05:39 UTC
I can report that it doesn't work if you browse to a song where the album doesn't have artwork.

i.e. when browsing to a song, it reads changed tags, but artwork fetching in this way is still iffy.  Sequence of steps:

1. I had run a scan for new/changed albums
2. It detected a few new albums since my last scan, but I had forgotten to store artwork for one album, and I also noticed a typo in the album name.
3. I changed the album name tag for each song, and added a folder.jpg in the folder.
4. I browsed down into song info for each song on the album.
5. This caused it to re-read tags for each song.
6. The album name is correctly displayed in the New Music list, and the album is first in the list.  The album artwork thumbnail is displayed in this list.
7. Browsing into the album displays the correct album name, but the artwork is not displayed (even after refreshing the page in the browser).
8. Browsing to songs on the album shows the correct album name, but the artwork is not displayed.
9. Browsing into View Tags for each song shows the correct tags, but not the artwork.

Incidentally, I get the opposite effect with another new album - the artwork isn't displayed in New Music, but is displayed when I browse the album or songs on the album.
Comment 15 Andy Grundman 2009-11-01 08:56:24 UTC
Note this is only fixed in the embedded branch...
Comment 16 Chris Owens 2010-04-06 09:07:07 UTC
Andy notes this is now fixed in 7.6.0
Comment 17 Chris Owens 2010-04-12 09:02:39 UTC
Mickey please put a comment about what to discuss in the bug meeting
Comment 18 Paul Chandler 2011-04-28 09:05:21 UTC
(In reply to comment #17)
> Mickey please put a comment about what to discuss in the bug meeting

IT gets the artwork with the scan (for new and changed music)