iRiver filename truncation

[hmoffatt]

The iRiver 52 character filename truncation can result in files with no extension.. eg the .ogg extension is lost.

I synced a few albums over to my H140 with long filenames and found that when I tried to play them on the H140, some tracks wouldn't play, possibly because they didn't have recognised extensions.

Also, the tracks didn't seem to be listed in order on the player, which was strange. Is there a database dump tool I can use to check the iRiver database by hand?

thanks,
Hamish

[ukandrewf]

i think you just have to ensure that your files are no longer than 48 characters +4 for the extension ie .ogg and you should be fine.

[hmoffatt]

i think you just have to ensure that your files are no longer than 48 characters +4 for the extension ie .ogg and you should be fine.

How do you propose that I do that?! Rename 4K files manually?

The latest alpha has a filename truncation option which ensures that filenames on the device are <= 52 characters long, as the H1xx requires. However it looks like it does not necessarily preserve the extension, and the H140 seems to need it.

It's the whole path name that's important, not just the base filename and extension.

Hamish

[jiri]

MM shouldn't remove the extension on synchronization. Could you check what's the original filename and what is the synchronized version (i.e. how was is truncated)?

Jiri

[hmoffatt]

MM shouldn't remove the extension on synchronization. Could you check what's the original filename and what is the synchronized version (i.e. how was is truncated)?

Well I have my "Synchronize tracks to" format set to:
\<Genre>\<Album>\<Title>

I have a file
C:\mp3\Brass\DePaul University Wind Ensemble - Volume Three\06-Eric Ewazen Concerto for Bass Trombone and Wind Ensemble -- Allegro ritmico.ogg

Genre = Tuba
Album = "Volume Three"
Title = "Ralph Vaughan-Williams Concerto for Basstuba -- Rondo alla Tedesca"

The resulting file after sync is

\Tuba\Volume Three\Eric Ewazen Concerto for -- Wind Ensemble-Allegro ri

No extension. 3 out of 10 tracks got copied over without extensions.

I can supply a copy of the file if that's helpful.

thanks
Hamish

[hmoffatt]

The resulting file after sync is

\Tuba\Volume Three\Eric Ewazen Concerto for -- Wind Ensemble-Allegro ri

Also, I notice that the whole filename is ~71 characters in length, while the base filename is 52 characters. I think the H1xx requires that the entire filename (including whole path) is 52 characters?

Hamish

[jiri]

You were right, there was a problem in truncation. I uploaded a modified version of the device plug-in to http://www.mediamonkey.com/beta/d_iRiverH.dll , you can replace the one in Plugins folder.

As far as I know the 52 limit applies to each part of the full path. However I cannot test it because I only have H320 which doesn't have such limit at all.

Jiri

[hmoffatt]

You were right, there was a problem in truncation. I uploaded a modified version of the device plug-in to http://www.mediamonkey.com/beta/d_iRiverH.dll , you can replace the one in Plugins folder.

As far as I know the 52 limit applies to each part of the full path. However I cannot test it because I only have H320 which doesn't have such limit at all.

Thanks, that fixes the filename extension problem.

I think you are right about the 52 characters per element. I had a file called \Tuba\Volume Three\Edward Gregson Tuba Concerto -- Allegro deciso.ogg which played ok. (The final part is < 52 characters (without truncation) but the whole path is longer.)

However I have a problem still in that filenames that were truncated during sync don't play from the DB properly. The iRiver just doesn't play them when you select them. Filenames that didn't have to be truncated are okay.

thanks,
Hamish

[jiri]

As I wrote I don't have H140 and so I can't test it right now, but from what I reviewed the DB should be ok (i.e. the filenames there are also properly truncated to 52 characters). Maybe you could try to delete iRivNavi.iDB file from the device completely and let it MM create again (right click on the device in MM). Possibly there just something wrong remained from the incorrectly truncated files...

Jiri

[hmoffatt]

As I wrote I don't have H140 and so I can't test it right now, but from what I reviewed the DB should be ok (i.e. the filenames there are also properly truncated to 52 characters). Maybe you could try to delete iRivNavi.iDB file from the device completely and let it MM create again (right click on the device in MM). Possibly there just something wrong remained from the incorrectly truncated files...

Do you do anything particularly special with the encoding of text in the database entries? eg use Unicode?

I found a utility called iFish (find it on sourceforge) which allows you to view the database from the player. I read in my database created using TDT and it looked fine. Then I removed that and created a database with Media Monkey, and all the characters look trashed in iFish. Very strange.

Even with a fresh database, the player won't play some of the files from the MM-created database. Obviously I need to find a different database viewer because iFish isn't doing the trick.

thanks,
Hamish

[hmoffatt]

I found a utility called iFish (find it on sourceforge) which allows you to view the database from the player. I read in my database created using TDT and it looked fine. Then I removed that and created a database with Media Monkey, and all the characters look trashed in iFish. Very strange.

Even with a fresh database, the player won't play some of the files from the MM-created database. Obviously I need to find a different database viewer because iFish isn't doing the trick.

OK, it turns out that your database is in UTF-16 and iFish just needed a settings change to read that correctly.

Hamish

[Rusty - not logged in]

Hamish,

Please let us know what you find re. what the problem is regarding some tracks that aren't read by the H140/H120.

btw, if you look at the db on that device that is created by default, is unicode enabled? I'm wondering if there are bugs in the device regarding handling of unicode vs. a problem in the DB format that MM is creating.

-Rusty

[hmoffatt]

Hamish,

Please let us know what you find re. what the problem is regarding some tracks that aren't read by the H140/H120.

btw, if you look at the db on that device that is created by default, is unicode enabled? I'm wondering if there are bugs in the device regarding handling of unicode vs. a problem in the DB format that MM is creating.

It looks like databases created with TDT are not Unicode encoded. I don't know what happens with iRiver's own software, as it crashes on almost all of my OGG files.

I do have a one whole album in the TDT database which the iRiver won't player either.

I synced a single album of 10 tracks with MM. 5 of those tracks don't play, and all of them have 52 character filenames. The 5 that do play all have shorter filenames. However, my TDT-created database contains many files with 52 character names that do play OK.

Maybe the H140 has a problem with 52 character names in Unicode format. Is it possible to make the format and/or the maximum length configurable so that I can experiment until it works?

regards
Hamish

[hmoffatt]

It looks like databases created with TDT are not Unicode encoded. I don't know what happens with iRiver's own software, as it crashes on almost all of my OGG files.

OK, very confused now. Found the following.

Using the filenames created by MediaMonkey (truncated to 52 characters),

Unicode Database by MM -> 5 files (52 character names) won't play
Unicode Database by iFish -> same files won't play
ISO-8859-1 database by TDT -> all files play fine
ISO-8859-1 Database by iFish -> all files play fine

Must be a firmware bug.

Hamish

[jiri]

There was a new version uploaded to http://www.mediamonkey.com/beta/d_iRiverH.dll

It has on option to select whether to use ASCII or Unicode DB format. It should help in your case.

Jiri