Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 54
  1. #11
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    ok, 4 scans further with different sets: The "you&me" issue seems to be back - and there seems to be another issue with casesensivity (Atb => ATB, just tried A-ha => a-ha and R3HAB => R3hab)

    Next test will be tommorow set I set back my library.db to an old backup (I've one from 02.02., that should be just after my initial scan) and make a n&c scan with a nightly from 04.02. and/or 05.02. - I will report...

  2. #12
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,749

    How does new&changed scanner detect whatfiles to scan?

    > ok, 4 scans further with different sets: The "you&me" issue seems to be
    > back - and there seems to be another issue with casesensivity (Atb =>
    > ATB, just tried A-ha => a-ha and R3HAB => R3hab)


    Can't reproduce the case sensitive case: test with and without file name
    change. In both cases the change would be picked up as expected.

    Are you sure you're running the latest buid? And it would still be great
    to get access to the log and database files.

    > Next test will be tommorow set I set back my library.db to an old backup


    Keep in mind that one of the changes around case senstitivity require
    the file the be created anew. Restoring an older file will indeed
    re-introduce the problem.

    > (I've one from 02.02., that should be just after my initial scan) and
    > make a n&c scan with a nightly from 04.02. and/or 05.02. - I will
    > report...


    Please double check scanned_files.url is case insensitive ("collate
    nocase").

  3. #13
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    Quote Originally Posted by mherger View Post
    Are you sure you're running the latest buid?


    Yes, I'm always running the last nightly (check it before every scan ).
    I just today did a regression to 02.02. nightly to see if it shows anoter behaviour - it didn't.

    Quote Originally Posted by mherger View Post
    Keep in mind that one of the changes around case senstitivity require
    the file the be created anew. Restoring an older file will indeed
    re-introduce the problem.


    Yapp, I'm aware, I tested with a backup made after the initial scan (with Your database changes)

    Quote Originally Posted by mherger View Post
    Please double check scanned_files.url is case insensitive ("collate
    nocase").


    And once again Yes, I checked it, it is "text" "NOT NULL COLLATE NOCASE"

    And Yes, I see, if You can't reproduce I have to do some more tests maybe with a special test set (usually I do several changes everyday in my huge db , but I only track those "name changes".
    I will take the time to do nothing than those "name changes" and watch the logfiles. Now changed all 3 scanner logging-options to "debug"...
    Last edited by frank1969; 2022-02-07 at 07:08.

  4. #14
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    @mherger:

    So, here are my results and logs and "what obviously could have happened".

    In both cases it were misspelled artsist.
    Both were the only entries from those artists a) "ATB: Topic" b) "Deejay Ítzi"

    a) with renaming: changed "ATB: Topic" => "ATB; Topic" (as album artist and track artist) AND renamed the file
    b) without renaming: I changed "Deejay Ítzi => DJ Ítzi" (it's an album by "Various Artists" with comp=1 ) and DIDN't rename the file

    Important:
    I did it this weekend AFTER my initial re-scan using the (at that point) last nightly (should have been r1643836091 or 1644040271). From this "1st run" I don't have the logs (resp. only the "short log" with no details).

    Result:
    a) Track was in db with artists "ATB" and "Topic" - but the "ATB: Topic" artist stayed in with an "empty" entry,
    b) Track was in db with "Deejay Ítzi" AND "DJ Ítzi"

    After changing my logging options, I "touched" them (so that scanner sees them as new) and scanned again (with r1644170574.exe)
    (the first track results from another thing I did, changing the artist "Voxxclub" => "voxxclub" - THIS one worked and it sais "Removing unused contributor".

    My examples a) and b) he also found as "changed" - but didn't obviously do anything with them.

    (...)
    [22-02-07 17:17:44.8926] Slim::Utils::Scanner::Local::changed (969) Handling changed audio track file:///M:/V/voXXclub/Donnawedda Volksmusik/18 - voxxclub - Haeddi dadi wari.mp3
    [22-02-07 17:17:45.1879] Slim::Schema::Contributor::rescan (244) Removing unused contributor: 18303
    [22-02-07 17:17:45.9323] Slim::Utils::SQLiteHelper::updateProgress (442) Notify to server: [
    "progress:1644250658.81424||importer||M:|directory _changed||23||24||",
    ]
    [22-02-07 17:17:45.9353] Slim::Utils::SQLiteHelper::updateProgress (466) Notify to server OK
    [22-02-07 17:17:45.9357] Slim::Utils::Scanner::Local::changed (969) Handling changed audio track file:///M:/_Various/B/Bravo%20Hits%20030%20-%20CD%202/18%20-%20Deejay%20Oetzi%20-%20Hey%20Baby%20-%20Deejay%20Oetzi%20-%20Hey%20Baby.mp3
    [22-02-07 17:17:48.4268] Slim::Utils::Scanner::Local::changed (969) Handling changed audio track file:///M:/A/ATB/2021%20-%20Your%20Love%20(Single)/01%20-%20ATB%3B%20Topic%3B%20A7S%20-%20Your%20Love%20(9PM).mp3
    [22-02-07 17:17:54.2329] Slim::Utils::SQLiteHelper::updateProgress (442) Notify to server: [
    "progress:1644250658||importer||M:|directory_chang ed||24||24||1644250674.23192",
    ]

    So I looked in my library.db:

    in "contributors":
    both misspelled artists are still "in"
    a) ATB: Topic = 101413
    b) Deejay Ítzi = 68185

    in "contributor_album":
    a) 10143 is linked with "role 5" and "role 6" (NOT role 1) to one album (41226)
    b) 68185 is linked with "role 1" to one album (30954)

    in "contributor_track":
    a + b) both contributors DOESN'T exist.

    in "albums":
    a) album 41226 shows as contributor 10143
    b) album 30954 shows as contributor 3 ("Various Artists")

    in "tracks":
    a) album 41226 shows no result
    b) album 30954 shows track 439161 with primary_artist 5883 (which IS "DJ Ítzi", the correct contributor!)

    once again looking in "contributor_track"
    a) - (for there is no track)
    b) track 43961 has contributor 5883 (the correct "DJ Ítzi") with role 1 and contributor 3 ("Various Artists") with role 5

    So IMHO I guess (!) this is what happens:
    a) scanner recognized the RENAMED file,
    - added the new file to teh db "tracks" (which is there, track #1160846 with correct album and correct artists)
    - deleted the old file from "tracks" (I also CAN'T find it searching for the old URL),
    but did - not see, it was the only track from the album and did not delete the "unused album".
    - not see, the contributor has no more entries than this "unused album" and so did not delete the "unused contributor"

    b) scanner recognized the CHANGED file,
    - added the new (corrected) contributor to "contributor_track" and deleted the "wrong" contributor from "contributor_track"
    - added the new (corrected) contributor to "tracks" as "primary_artist"
    - did not add the new (corrected) contribuotr to "contributor_album" and did not remove the "old" contributor from "contributor_album"
    - did not see that the "old" contributor is "unused" (which scanner couldn't see, for it is still in use in "contributor_album")

    Would any more information be helpful I could look up for You?

    Maybe this gives You a hint - otherwise I will start another test with a similar case - and this time log "everything" again...

  5. #15
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,749

    How does new&changed scanner detect whatfiles to scan?

    > In both cases it were misspelled artsist.
    > Both were the only entries from those artists a) "ATB: Topic" b) "Deejay
    > ├ľtzi"
    >
    > a) with renaming: changed "ATB: Topic" => "ATB; Topic" (as album artist
    > and track artist) AND renamed the file
    > b) without renaming: I changed "Deejay ├ľtzi => DJ ├ľtzi" (it's an album
    > by "Various Artists" with comp=1 ) and DIDN't rename the file


    With the information I have I can't reproduce the issue. I tried to
    follow both. But I'm missing pieces:

    - what't the compilation's album artist (literally)?
    - what are your settings in Settings/My Music?

    I think it has something to do with the artist roles. Therefore the last
    point could be crucial, as I don't include composers, conductors etc. in
    my collection.

    > So IMHO I guess (!) this is what happens:
    > a) scanner recognized the RENAMED file,
    > - added the new file to teh db "tracks" (which is there, track #1160846
    > with correct album and correct artists)
    > - deleted the old file from "tracks" (I also CAN'T find it searching for
    > the old URL),


    Deletion happens before the addition.

  6. #16
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    Quote Originally Posted by mherger View Post
    >- what't the compilation's album artist (literally)?
    It's named "Various Artists" (see below)

    Quote Originally Posted by mherger View Post
    - what are your settings in Settings/My Music?
    - Use singe, configurable list of artists
    - Composer, band... NOTHING is checked
    - List compilation albums under each artist
    - Treat TPE2 MP3 tag as Album Artist
    - When compilation albums are grouped together, they appear under "Various Artists" by default. You can change that name below. (I typed Various Artists again, though I know it's repeated unnecessarily)
    - Show all albums and tracks for an artist
    - Only show tracks or albums matching the selected role for an artist
    - Search withing words
    - The El La Los Las Le Les Der Die Das
    - ;
    - 200
    - Treat multiple disc-sets as multiple albums
    - Remember playlist
    - Leave in same order
    - Save playlists in order songs were added

    Quote Originally Posted by mherger View Post
    I think it has something to do with the artist roles. Therefore the last
    point could be crucial, as I don't include composers, conductors etc. in
    my collection.
    This is what I do - I guess... (see above)

    Quote Originally Posted by mherger View Post
    Deletion happens before the addition.
    OK, mentioned it in random order for I didn't know...

  7. #17
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,749

    How does new&changed scanner detect whatfiles to scan?

    > a) with renaming: changed "ATB: Topic" => "ATB; Topic" (as album artist
    > and track artist) AND renamed the file
    > b) without renaming: I changed "Deejay ├ľtzi => DJ ├ľtzi" (it's an album
    > by "Various Artists" with comp=1 ) and DIDN't rename the file


    Thanks for the additional information! I believe I now got the "DJ ├ľtzi"
    case covered, too. Hopefully it doesn't break too many things... I'm
    still struggling to reproduce the case which renames files/folders. This
    could be a Windows problem. I'll have to see whether I can fire up some
    VM to reproduce the issue.

    New build is on its way.

  8. #18
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    Thanks for the build.

    Just a note:
    I tested by "touching" the files again (changing mtime) so they were discovered by scanner.
    It did but it did no changes to the db.
    Am I right that this is "expected behaviour" for scanner didn't see that the old "Deejay Ítzi" artist is as orphaned entry still connected to the album in contributor_album?

    If then I would try to create a new "Deejay Ítzi => DJ Ítzi"

  9. #19
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,749

    How does new&changed scanner detect whatfiles to scan?

    > I tested by "touching" the files again (changing mtime) so they were
    > discovered by scanner.
    > It did but it did no changes to the db.
    > Am I right that this is "expected behaviour" for scanner didn't see that
    > the old "Deejay ├ľtzi" artist is as orphaned entry still connected to the
    > album in contributor_album?


    Yes, I believe this could be true: the cleanup happens when the content
    changes. But despite the updated timestamp, the scanner would not have
    seen an updated artist.

  10. #20
    Senior Member
    Join Date
    Jun 2009
    Posts
    497
    Quote Originally Posted by mherger View Post
    >Yes, I believe this could be true: the cleanup happens when the content
    changes. But despite the updated timestamp, the scanner would not have
    seen an updated artist.
    OK, thanks - then I will now turn the files back in "broken" status => scan => correct the tags => scan ...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •