Sync File Masks Filenames [#16901][#16902]

[CosmicKnowledge]

The [FilenameMappings] method failed on sync?

Assuming input files use UTF8 RFC 3629 specs for meta data fields, that's 2^21 or 2,097,152 possible characters to deal with (minus the basic ASCII table). I'm dealing with input files that have Chinese, Japanese, and who knows what kind of characters in their meta-data and filenames.

[Lowlander]

Most players are not that limited when it comes to supported characters, but it's being looked at in the few cases this can be a problem.

[CosmicKnowledge]

I don't know what characters the device can use. It's a Sony NW-A55. Their "tech support" is limited to replies like "restore to factory defaults", "use the Sony sync software", or "you can send it in for repair". Mind you, this is with the question "what charactersets can the device use in filenames?".

I had much better success with <autonumber> and <random> except that they inflated the total space requirement by 5x and thus unworkable.

So, until it's addressed by programmers, I have a paperweight (MM and the player). I hope it's fixed in the near future. I just purchased MM a few weeks ago and I can't seem to use it because of this. (MM5 alpha is also in a perpetual startup crash loop and I don't dare let it touch my original files and database)

[Lowlander]

A solution is proposed here: https://www.ventismedia.com/mantis/view.php?id=16901

[CosmicKnowledge]

A solution is proposed here: https://www.ventismedia.com/mantis/view.php?id=16901

Thanks for finding that. I did read it carefully. I think it begins to scratch the surface but will not fix it. I think what I mention needs its own requirement instead of having this existing MM5 requirement hopefully overlap sufficiently. I do address several other critical details such as the non-repetition of songs across multiple playlists. That, any other aspects, are not covered by that existing requirement.

[Lowlander]

It should fix your problem entirely as you're not using some logic tag based naming convention (so this would be as good as any) and should provide a work-around the seemingly limited capabilities of the device.

[CosmicKnowledge]

It should fix your problem entirely as you're not using some logic tag based naming convention (so this would be as good as any) and should provide a work-around the seemingly limited capabilities of the device.

How can you say that it will fix things if the one example of a deficiency I mentioned is not in that requirement?

Are you just hoping that it works the way you think it does?

I think that requirement needs to be ammended because the easy thing for the programmer to do is NOT to change the existing logic, which means that the uniqueness assembly is scoped to playlist by playlist, resulting in duplicated songs with different filenames. That's already the problem.

I don't understand what the hesitancy is to writing good requirements that cover every deficiency.

[Lowlander]

Duplicates would be solved as it uses the unique file ID in the database, thus it won't create duplicates as the filenames are the same. Ie. as long as your Mask doesn't lead to a unique Filename depending on where it is selected to be synced, no matter how many copies are selected it would have 1 file on device as result.

So if your Mask is \Music\<Track ID> it would create a single copy of the file, no matter how many Playlists it is associated with.

Other solutions are still being considered as well: https://www.ventismedia.com/mantis/view.php?id=16902

[CosmicKnowledge]

Duplicates would be solved as it uses the unique file ID in the database, thus it won't create duplicates as the filenames are the same. Ie. as long as your Mask doesn't lead to a unique Filename depending on where it is selected to be synced, no matter how many copies are selected it would have 1 file on device as result.

So if your Mask is \Music\<Track ID> it would create a single copy of the file, no matter how many Playlists it is associated with.

Other solutions are still being considered as well: https://www.ventismedia.com/mantis/view.php?id=16902

That does sound like it could work. I hope that also fixes missing tracks on the player across various playlists too.

[Ludek]

I don't like that adding <Track ID> as mask, this is internal ID in MM database and is unique only to a single instance of MM.
i.e. when user deletes a track from database and re-scans then it gets different <Track ID>

I think that users already can use something like:

Code: Select all

$Len(<Title>) -- <length>

It is mostly unique and if not then MM auto-adds numbered suffix (without creating duplicates like in case of <AutoNumber>)
Note that for <AutoNumber> it creates duplicates intentionally, see issue https://www.ventismedia.com/mantis/view.php?id=6343 for details

[Lowlander]

That's the point, that it creates a unique value, but without using the tags that are full of unsupported characters.

It would be a minor problem if the user switches MediaMonkey database (new TrackID's) requiring removal and resync in that scenario.

[Ludek]

$Len(<Title>) -- <length> also creates unique value (adds numbered suffix without creating multiple copies of the same file on the devcie) and includes just numbers (so meets alfanum form) + can be used even with MM4.