$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.

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.

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

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]
$Len(<Title>) -- <length>
[/code]

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

[quote=Lowlander post_id=471896 time=1598134339 user_id=262]
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
[/quote]

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

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

[quote=Lowlander post_id=471893 time=1598133884 user_id=262]
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.
[/quote]

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.

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.

[quote=Lowlander post_id=471891 time=1598132986 user_id=262]
A solution is proposed here: https://www.ventismedia.com/mantis/view.php?id=16901
[/quote]

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.

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

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)

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.

[quote=Lowlander post_id=471871 time=1598118750 user_id=262]
The [FilenameMappings] method failed on sync?
[/quote]

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.

[quote=Lowlander post_id=471871 time=1598118750 user_id=262]
The [FilenameMappings] method failed on sync?
[/quote]

Did not solve the problem. Not to mention the charactersets are huge. It's not just one or two characters. What is needed is a new function in the sync mask logic called ConvAlpha() which strips/converts non-alpha characters to strictly numbers and letters.

Not to mention, this really should be a developer solution rather than a customer one. Pretending I know nothing about computers, syncing doesn't work properly.

The [FilenameMappings] method failed on sync?

PC                  Playlist         Music Device
================   ===========       =============
MySong1.mp3   --->  Playlist 1  -->  Song1.mp3
              --->  Playlist 2  -->  Song2.mp3
              --->  Playlist 3  -->  Song3.mp3
              --->  Playlist 4  -->  Song4.mp3

[quote=Lowlander post_id=471869 time=1598117795 user_id=262]
Correct, if a filename is unique MediaMonkey respects that and creates the multiple copies.
[/quote]

The input filename is not unique. MM is unnecessarily creating copies of the same input file onto the SD card because it appears to process every playlist separately rather. MM does not use the same output file if that file is used across various playlists.
[code]
PC Playlist Music Device
================ =========== =============
MySong1.mp3 ---> Playlist 1 --> Song1.mp3
---> Playlist 2 --> Song2.mp3
---> Playlist 3 --> Song3.mp3
---> Playlist 4 --> Song4.mp3

[/code]

[b]This is a big problem that MM developers need to address[/b] because I can't sync due to the huge space requirements of creating so many unnecessary copies. I wish a programmer would contact me personally so I could show them the situation. There's also a problem where playlists on the device end up having less songs than the playlists on the PC.

Bottom line, I don't think there is a solution right now without developers fixing this in MM.