PDA

View Full Version : 7.41 art scan on 'look for new and changed'?



bobkoure
2009-10-16, 18:37
Not a big deal, but it when I add a couple of albums and use the "look for new and changed music" the artwork isn't scanned in.
On the Information page, there isn't an artwork scan listed at all. I'd paste that in, but copy/paste from that panel gets all scrambled up.
The scanner log shows that there was an artwork scan, but that it was over in 0 seconds (snipped from scanner log pasted below.

Not a major deal as the artwork gets added if I visit the album with the web UI, then refresh.
But this might be a bug.
Anyone have any idea if it is?

Oh - it's Version: 7.4.1 - r28887 on a windows 2k server. Art is in separate 'cover.jpg' files



[09-11-16 16:27:55.1938] Slim::Music::Import::endImporter (701) Completed mergeVariousAlbums Scan in 343 seconds.
[09-11-16 16:27:55.2180] Slim::Music::Import::runScanPostProcessing (438) Starting artwork scan
[09-11-16 16:27:55.3004] Slim::Music::Import::endImporter (701) Completed findArtwork Scan in 0 seconds.

kdf
2009-10-16, 18:57
https://bugs.slimdevices.com/show_bug.cgi?id=4565

https://bugs.slimdevices.com/show_bug.cgi?id=13315

and this last one is the bug under which some code was added that adds
artwork where possible when browsing and finding missing artwork.
https://bugs.slimdevices.com/show_bug.cgi?id=4631

-kdf

bobkoure
2009-10-16, 19:26
Thanks!
I "voted" for 13315.
I use SB3s. I'm surprised controller users aren't up in arms over this one.

Mnyb
2009-10-16, 23:33
And this one

https://bugs.slimdevices.com/show_bug.cgi?id=14198

loks like a dupe of 13315 to me ?

kdf
2009-10-16, 23:35
broken down to basics, it's a dupe of all 3 bugs that I posted. They
are all so tightly related that any fix for one, will fix all.
-k

On 2009-10-16, at 11:33 PM, Mnyb wrote:

>
> And this one
>
> https://bugs.slimdevices.com/show_bug.cgi?id=14198
>
> loks like a dupe of 13315 to me ?
>
>
> --
> Mnyb
>
> --------------------------------------------------------------------
>
> No it can NOT be controlled with iTunes....
> ------------------------------------------------------------------------
> Mnyb's Profile: http://forums.slimdevices.com/member.php?userid=4143
> View this thread: http://forums.slimdevices.com/showthread.php?t=69894
>
>

Mnyb
2009-10-16, 23:50
And sadly these:

https://bugs.slimdevices.com/show_bug.cgi?id=8303
https://bugs.slimdevices.com/show_bug.cgi?id=9919

Over a year old bug s .

I think they done and are doing a big mistake .
Artwork could have been working properly a year ago without these blockers.
They are working on the concept that the new "improved scanner / new schema database" will solve all issues , therefore solving these bugs are a waste of time . But 1 year had passed..

And they churn out new products all the time further delaying all such efforts.
It's turning into a search for the holy grail ? have it been found yet .And most importantly did it exist at all to begin with ;)

JJZolx
2009-10-16, 23:57
And sadly these:

https://bugs.slimdevices.com/show_bug.cgi?id=8303
https://bugs.slimdevices.com/show_bug.cgi?id=9919

Bug 9919 basically states "we need to start all over with how artwork is handled". It's never worked particularly well. I don't think it requires or depends on a new database schema for the rest of the library, although it would require a couple of new tables. The real work is in the coding, as almost everything about finding, scanning and cataloging artwork would change.

kdf
2009-10-17, 00:03
Exactly. Any anyone who thinks this is simple, is basically clueless.
You don't make this kind of rework without time, and sadly the return
on investment for these types of changes is too low to make it
something that happens instead of new product or fixing lower hanging
fruit.

Not to mention that artwork handling came about via third party
contribution. Given that all third party stuff faces limitations due
to lack of direction from "management", you lose the finesse in trade
for having the feature at all.

-k
On 2009-10-16, at 11:57 PM, JJZolx wrote:

>
> Mnyb;473373 Wrote:
>> And sadly these:
>>
>> https://bugs.slimdevices.com/show_bug.cgi?id=8303
>> https://bugs.slimdevices.com/show_bug.cgi?id=9919
>
> Bug 9919 basically states "we need to start all over with how artwork
> is handled". It's never worked particularly well. I don't think it
> requires or depends on a new database schema for the rest of the
> library, although it would require a couple of new tables. The real
> work is in the coding, as almost everything about finding, scanning
> and
> cataloging artwork would change.
>
>
> --
> JJZolx
>
> Jim
> ------------------------------------------------------------------------
> JJZolx's Profile: http://forums.slimdevices.com/member.php?userid=10
> View this thread: http://forums.slimdevices.com/showthread.php?t=69894
>
>

JJZolx
2009-10-17, 00:14
And this one

https://bugs.slimdevices.com/show_bug.cgi?id=14198

loks like a dupe of 13315 to me ?

That bug is different. It basically states that when you add artwork for an _existing_ album that it's not found by a new & changed scan. I don't recall for certain, but did that _ever_ work without doing a full clear/rescan?

Mnyb
2009-10-17, 00:26
Yeah i'm clueless :) but you're spot on it is a business decision ultimately.
I'm actually glad that the controller in 7.4 now tries to emulate the touch/radio, thus sharing code ? squeezeplay it is (clueless remember ).
Therefore the controller gets some development and improvement too, nobody would have found resources for developing "controller only" features/bugs.

These bugs are annoying, but a full scan fix artwork to a somewhat working state in most cases.

The real sufferers are some corner cases with a huge collection and weak server NAS anyone ? But you must be into pain if you have a such a collection and still uses a slow NAS as a server ? some fellow in these bug reports have 12 hour scan times for a full scan.

bobkoure
2009-10-17, 07:01
So... speaking as a software engineer who hasn't looked into the architecture (so I could be really off base):
The problem is that the artwork scan is too deeply connected.
Make it a separate "product" (i.e. data/process hiding). All the artwork scan needs to know is the sizes to cache and how to hand the data (pointer to a file? blob?) over when requested. Want to make the hand-over more efficient? Have the art scan request a "handle" for each track (don't try to mangle a name (or however it's currently done) the current way, but hide data in that direction as well.
This is basic stuff, based on the fact that engineers are human and can only manage so many things at once, Split a problem into smaller pieces and they can be attacked severally - and you have a better chance of success.