INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Problem with Handheld Sync Where Directory Name Would Have a Trailing Period  (Read 2442 times)

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5239
  • "Linux Merit Badge" Recipient

I have an issue with handheld sync with MC for Linux (using version 103).  Specifically, some files are not syncing, and I think I've narrowed it down to an issue with trailing periods. 

I have the sync options setup to place files in directories by [Album Artist]/[Album], and that works fine for 99% of files, but any artist or album that has a trailing period in its name throws an error during sync and does not sync.  As examples, the Rolling Stones album "Exile on Main St." will not sync,  and neither will any track by the artist "H.I.M.".  Interestingly, the sync seems to create the directories successfully, but then errors out before copying any files or additional sub-directories.  To follow my examples above, a directory called "Exile on Main St." is created under Rolling Stones, but is empty.  Similarly, a directory called "H.I.M." is created but no subdirectories for any albums are created.

This seems to be the case whether I sync to an actual handheld or to some directory on my NAS (which are shared via samba); I get the same results in either case.  When I try to sync to the same handheld using the Windows version of JRiver and the same directory rules, the files all sync, and I see them correctly on my device.  One key difference though is that when I look at the filesystem, the directories Windows JRiver creates lack the trailing period (i.e. Windows JRiver made a directory called "H.I.M" and "Exile on Main St" and filled them with the appropriate files). 

I assume this is some kind of issue with cross platform file naming conventions and/or file system compatibility?  I only recently started using the handheld sync function on JRiver for Linux, so I don't know how long this has been an issue.  Let me know if I can provide any more info!
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13931

My guess that it's been in the linux/Mac versions forever.
Will try to get a look at it.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5239
  • "Linux Merit Badge" Recipient

My guess that it's been in the linux/Mac versions forever.
Will try to get a look at it.

Thanks Bob! Let me know if you have any trouble reproducing.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13931

Are you converting on the fly?
I tried it on Mac and it worked ok, haven't had a change to try Linux yet but it should be same as the Mac.
What is the filesystem of your handheld/NAS ?
I was using Fat32.
Logged

bob

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 13931

Ok, interesting, on fat32 a trailing . is actually illegal for directory names.
We were handling that on windows automatically. The linux and Mac filesystems can handle it OK but of course not fat32 connected handhelds.
So we are going to strip that trailing . when writing to a handheld device on all platforms, not just windows.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5239
  • "Linux Merit Badge" Recipient

Ok, interesting, on fat32 a trailing . is actually illegal for directory names.
We were handling that on windows automatically. The linux and Mac filesystems can handle it OK but of course not fat32 connected handhelds.
So we are going to strip that trailing . when writing to a handheld device on all platforms, not just windows.

I was converting on the fly, and it sounds like you figured it out, thanks! 

The handheld is FAT32 or EXFAT.  The NAS uses btrfs locally, but exposes the filesystem to JRiver via samba, and samba adds windows-esque filesystem constraints.  For example, I ran into an issue where I unintentionally had duplicate directories with differing case (e.g. "Nick Cave and the Bad Seeds" + "Nick Cave And the Bad Seeds"), which is fine and legal on linux native FSes, but when I shared them via samba, the clients couldn't see both directories at once and it led to weird results.
Logged
Pages: [1]   Go Up