Special characters in filename causes files not to be played
#1
I've got a collection of audioplays be "the three investigators". In german they are called "Die drei ???". 

Reading those files into the library works well, but they could not be played, as the path for the files ends after the second "?"...

Example: 
Code:
Hoerspiele/DDF/2017 - Die drei ??? 90-Minuten-Special: Das Grab der Inka-Mumie (other)/CD 01/Die drei ??? - 01 - Ein Mumienschrein in Rocky Beach.mp3
If kodi tries to play this file it looks for:
Code:
Hoerspiele/DDF/2017 - Die drei ??? 90-Minuten-Special: Das Grab der Inka-Mumie (other)/CD 01/Die drei ??
and can't find the file!
Playing the file from file-menu works fine. Even the "???" in the foldername give no problem! If I rename the filename to: "Die drei questionmarks - 01 - Ein Mumienschrein in Rocky Beach.mp3" it works!

So it seems the filename itself is not saved correctly into the DB!

I stumbled upon this as the hole source was removed when cleaning the DB and read in again on update DB.
Reply
#2
Interesting, I'll take a look. Sounds like a doubling of "?" being used as a escape char somewhere.

BTW I'm not ignoring your other questions of other threads, just short on time this weekend. I will get to them I promise Smile
Reply
#3
No problem Wink
Reply
#4
Ha, of course.... expected behaviour
Kodi is designed to be consistent cross-platform, and Windows has a list of reserved char that are not allowed in filenames (even if Linux will)
The following reserved characters:
< (less than)
> (greater than)
: (colon)
" (double quote)
/ (forward slash)
\ (backslash)
| (vertical bar or pipe)
? (question mark)
* (asterisk)

So "?" is not allowed. While some parts of Kodi may be generously coping other parts are not. Rename "the three investigators" Smile
Reply
#5
Why ever kodi has to take care of filename conventions. Isn't that a matter of the platform/os rather than an application that's just reading data?!
(BTW, the files are tagged and named with picard :-)

And what about the path? It contains "???", too... 🤔
Reply
#6
Have to add that this behavior is only happening when using libnfs. When using mounted nfs shares, files with even 5 question marks play fine...
Reply
#7
(2019-11-19, 09:15)Uatschitchun Wrote: Why ever kodi has to take care of filename conventions. Isn't that a matter of the platform/os rather than an application that's just reading data?!
Is it really so shocking or limiting that there are some reserved chars that are not acceptable in file and folder names? You may get away with it under some circumstances, but that doesn't mean it is guarantteed

Apart from OS limits Kodi itself deals with a wide variey of paths, some are URL with protocols etc., it uses are virtual file system for library items etc. This means that "?" or "|" in a path string is going to be interpreted in a specific way.
Reply
#8
Yes this is to be expected due to windows not supporting the question mark character. The fix is indeed to rename it.

As a windows user who has played this artists a few times most releases just drop the question marks.

If you have musicbrainz tags you can just save it in musicbrainz picard with the MBID and it will lookup online fine after that.

EDIT: just to say you can also use "The Three Question Marks" on TADB to look them up. https://www.theaudiodb.com/artist/116753
Image Image
Reply
#9
Files with those special characters work fine when adding the nfs-share mounted to the file system. They do not work when using kodi's libnfs implementation!

Those files are tagged and named with picard! They work as they should with no restrictions, so it's a libnfs restriction.
They also do play well when using libnfs and accessing them from file mode!

So:
Libnfs + file mode = works
Libnfs + database = works not
Kernel nfs + file mode = works
Kernel nfs + database = works

There are a lot of tracks (recordings) and releases in musicbrainz with special characters btw!

Quote:Is it really so shocking or limiting that there are some reserved chars that are not acceptable in file and folder names?
No, it's not shocking, but limiting, as there are a few limitations when using libnfs that aren't present when using native nfs!
Reply
#10
I'm not sure that file names are all that important with tagged music?  Anyway if it is a "seeing" thing, not related to doing automated search or filter you can always use the expedient of grabbing from the unicode half/fullwidth block from FE00 (though some search programs can normalize these to equate to the "normal" ones).

!"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ー

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
#11
Seen, it's not about my viewing pleasure, but it's the little things "hidden" within kodi I'm stumbling about.
I'm running nfs for ages now and haven't had any issues with my filenames. Tagging and renaming music with picard included.
So it's just annoying to recognize, without knowing beforehand, that there's a difference in using libnfs vs kernel nfs in regards to filenames.
(btw, it's the second limitation I'm stumbling about in regards to libnfs vs kernel nfs: 348770 (thread) )

The annoying thing is that if you've organized your media, tagged, named, etc, and scanned in some good amount of data, just to recognize that there's a difference between libnfs and kernel nfs you were not aware of beforehand as you were believing in nfs=nfs.

So I just don't get why any character in a filename works when scanning in from a mounted share vs using libnfs. Even the not working files work well with libnfs + file mode.

I wasn't aware of these limitations with libnfs (filenames, links). So my choices are:
 
  • Use native nfs on all devices
  • Seach and replace "illegal" characters
  • Re-scan all media with picard and use "windows compatibility filenaming" to rename all (including the need of syncing all to the backup

All that require scanning in all media again...

So, if only I would be able to understand, why there's a limitation in regards to filenames with libnfs vs kernel nfs, while paths may contain "illegal" characters (even with libnfs) and filenames may contain them, too, when using kernel nfs.

There maybe should be a Wiki entry comparing libnfs and kernel nfs. This one: NFS (wiki) does not state anything in regards to "illegal" characters or differences between libnfs and kernel nfs. My honest believe btw is, that there's no difference between libnfs and kernel nfs but a difference in how kodi handles the one and the other....
Reply
#12
I do understand/appreciate your frustration.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Krypton
Leia
Reply
#13
You appreciate me being frustrated? Thx dafür :-)

I'm not alone!
16383 (GH issue)
Reply
#14
Perhaps this issue arises because libnfs is cross-platform and kernel nfs obviously isn't. Huh  Just a thought.
Learning Linux the hard way !!
Reply
#15
I filed the issue on GitHub back in July. I think I did a pretty good job of figuring out why this changed for Kodi 18 (note: this never happened in previous version). I don't think the reasoning of reserved special characters applies because the code that's breaking on library scan isn't checking for special characters, it's checking for URI options and stripping them. See here: https://github.com/xbmc/xbmc/blob/55d75d...#L225-L236 What's that you say, you can't have URI options in an nfs path? Exactly! And I think that's the bug: libnfs paths are going through a URI check because the path is nfs:// but that's not the correct thing to do. As I pointed out in my GitHub bug, smb files erroneously go through this code path as well, though it has no effect since smb files must be Windows compatible.

To summarize: this isn't about special characters and uniformity across platforms. It's about improperly identifying libnfs files as URIs and applying options/parameter stripping logic to those paths. The fix should be as simple as updating IsURL to return false for nfs:// and smb://.
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
Special characters in filename causes files not to be played00