Working on a plugin - Scanning question

[mamema]

I wonder if musicbrainz_releasetrackid is unique ?
I don’t remember which tag LMS writes to the tracks table but that should be easy for you to see by looking at the tracks table for this music file.

yes will do, also with tracks which have several release version.
At the moment my whole library got scanned with index on the trackstat temp table. Will see if this helps.
Report here my findings

[mamema]

yes will do, also with tracks which have several release version.
At the moment my whole library got scanned with index on the trackstat temp table. Will see if this helps.
Report here my findings

so, confirmed, i have duplicates in temp_track_statistics. In library.db there is no additional musicbrainz track id, but another interesting value, which i'm now thinking about to use to tackle this duplicate issue. It's "filesize". musicbrainz_id and filesize shouldn't be duplicate that easy.... should work with several file formats.

BTW: my 3 hour run was interrupted with a watchtower (docker) refresh of the LMS container. :-) So Michael is very active.

[erland]

so, confirmed, i have duplicates in temp_track_statistics. In library.db there is no additional musicbrainz track id, but another interesting value, which i'm now thinking about to use to tackle this duplicate issue. It's "filesize". musicbrainz_id and filesize shouldn't be duplicate that easy.... should work with several file formats.

I’m guessing file size might change when changing tagging ?
However, it’s certainly better than the current solution, as long as the logic only operates on tracks which can’t be joined using url you are probably fine. The corner case it would potentially loose data in would be if the user both changes tags and move/rename a file, assuming file size changes if you edit tags of course.

[mamema]

I’m guessing file size might change when changing tagging ?
However, it’s certainly better than the current solution, as long as the logic only operates on tracks which can’t be joined using url you are probably fine. The corner case it would potentially loose data in would be if the user both changes tags and move/rename a file, assuming file size changes if you edit tags of course.

yes, file size changes, so the whole file is different. Which at the end could always be the case it someone tags files. Even i i would introduce a special hash value for trackstat.

[mamema]

yes, file size changes, so the whole file is different. Which at the end could always be the case it someone tags files. Even i i would introduce a special hash value for trackstat.

added the filesize to the dbcreate.sql
https://github.com/mamema/lms-tracks...e/dbcreate.sql

and to the query
https://github.com/mamema/lms-tracks...orage.pm#L1324

[erland]

added the filesize to the dbcreate.sql
https://github.com/mamema/lms-tracks...e/dbcreate.sql

Should work for testing purposes in an empty database but dbcreate.sql only runs if the table doesn’t exist so it won’t work in an existing installation that already have TrackStat installed. In a new plugin version you need to put this in a separate scrip that uses alter table to add the column. Compare with how urlmd5 column is added through the dbupgrade_urlmd5.sql script which is executed by the Perl code if the column doesn’t exist.

and to the query
https://github.com/mamema/lms-tracks...orage.pm#L1324

Looks like you have a linefeed and an extra c in the middle of the query.
Also shouldn’t the query check that file size is equal instead of not equal ? Thinking that you want to find entries with a non matching urlmd5 but which have the same musicbrainz id and same file size since this is likely a renamed/moved file. However, you need to verify it properly since you are the one that can run the code.

[mamema]

Hi Erland,

the linefeed and double c was a cut'n paste issue between VI and github. Corrected, thank you.
You're right, corrected the filesize query.