Really interesting file name handling problem

[Tamas-Toth-ebola]

Describe the bug (Required :red_circle:)

I investigate aprox. 2 hours for a very hardly catchable bug with the handling of the movie (and subtitle) filenames while retrieving them for further usage for the corresponding subtitle files, so hard to define it in short.

I had a movie and an external subtitle with the following filenames: A 1: B C - D E (1234) [h264 1080p • DTS 5.1].MKV A 1: B C - D E (1234) [h264 1080p • DTS 5.1].HU.SRT

When I tried to watch the movie I got no subtitle with Kodi through Google Drive while locally the same file(s) worked perfectly. I started to investigate and ha more tips/suspicion about them. First was the little bit long name. OK, tried with shorter ones. Usually worked but not always. These name sample of course the shortened version of the original. While original did not work this shortened one also does not work.

Let see forward. Maybe the special character (:) is the problem:

A 1 - B C - D E (1234) [h 1080p • DTS 5.1].MKV - notOK

Let see forward. Maybe the special character (•) is the problem:

A 1: B C - D E (1234) [h 1080p x DTS 5.1].MKV - OK

Wow, I got it. But not as I have lot of files (basically all my files use this schema) with really the same naming logic ([h264 1080p • DTS 5.1].MKV an its alternates based on the encoding). and all of them are working, eg.:

A - B (1234) [h264 1080p • DDP-Atmos 5.1].MKV - OK

Let see forward:

A 1: B C - D E (1234) [h 1080p • DTS 5.1].MKV - fewer chars - notOK A 1: B C - D E (1234) [h2641080p•DTS5.1].MKV - without some 'spaces' - OK

Hmmm. Maybe the 'spaces'. Spaces were never problems. Interesting. The suspicions are the 'spaces' and the • chars. Check them further with new schema:

1 2 3 4 5 6 7 8 9 0.MKV - Lot of 'spaces' - OK - Let define this as reference. 1 2 3 4 5 6 7 8 9 0 •.MKV - 1 more 'space' and a • - OK 1 • 2 3 4 5 6 7 8 9 0.MKV - 1 further more 'space' - notOK 1 • 2 3 4 5 6 7 8 90.MKV - 1 less 'space' - OK

Is it really the 'space'?

1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0.MKV - Lot more 'spaces' and chars - OK

So I really do not know what is exactly the problem. I thought firstly that the variable type what you use for store the retrieved video filename to then check for the corresponding subtitle is too short to store these data, but my investigations did not confirm it:(

The problem is relevant to the 'space' counts and to the • character. But clearly with more • the result is not worse. Also clearly with more 'spaces' the result is not worse. But there are some correlation between the two ('space' and •) as we get wrong result just with using those 2 chars.

Lot of thanks for your efforts and helps in advance!

To Reproduce (Required :red_circle:)

Steps to reproduce the behavior:

Check my detailed problem description. If you use same filenames you will get the same errors. Unavailable subtitles with the movies when used as external subtitles.

Your debug log file (Required :red_circle:)

As the problem clearly reproducible, I did not save logs for it.

Screenshots

Not needed.

[cguZZman]

Thanks for the detailed description, but the debug log file is required. The problem is not clearly reproducible. It could be the kodi version, it could be the lang used, it could be many things. A debug log file has details that can lead to the resolution faster, if there is actually an issue. I usually close issues opened without a debug log file, but because your detailed description I will make an exception and wait for it.

[cguZZman]

Make sure your log file is in debug mode and enabled before reproducing the problem.

[Tamas-Toth-ebola]

OK! Will get it. But please note, what I did not write in the original post, that the problem is clearly available on my 4 different environments.

I got exactly the same 'problematic' result with:

• Latest Kodi - Matrix on Ubuntu 20.10
• Latest Kodi - Matrix 64bit on Galaxy S10 with Android 11
• Latest Kodi - Matrix 32bit on Google Chromecast with Google TV
• Latest Kodi - Master nightly on SONY tablet with Android 9

All of them give me the same result.

But in a few minutes I will attach the logs of my desktop machine as that is the most easier now.

[Tamas-Toth-ebola]

Here is the log with one of the working filename and with one of the problematic one. I marked the 2 relevant parts of the file:

1. ----- Starting video with WORKING filename -----
2. ------ Starting video with PROBLEMATIC filename -----

Both of them working fine except that the problematic one simply does not load the corresponding subtitle, while the other one load it.

kodi.log

Thanks for your help in advance!

[cguZZman]

Your log shows that the addon found and assigned the subtitle correctly. Kodi later had an issue when reading the subtitle from your drive. It failed with "source read hit eof"

2021-04-05 11:36:04.238 T:89543   DEBUG <general>: Thread FileCache start, auto delete: false
2021-04-05 11:36:04.255 T:89543   DEBUG <general>: Process - <https://www.googleapis.com/drive/v3/files/*****?alt=media|Authorization=******> source read hit eof
2021-04-05 11:36:04.308 T:89543   DEBUG <general>: Thread FileCache 139636584195648 terminating

So looks like a kodi issue. Try with an stable version of Kodi, like version 19 or 18. You are currently running the 20 alpha version of Kodi. You could also report this issue to Kodi team.

[Tamas-Toth-ebola]

Hi!

Thanks for your fast response and sorry, I simply had not more time to investigate it further. But at least today had some more.

Your fast response is logical but I have to say that the situation is far not so clear, and easily closable.

You are right! I made a mistake as in the test cycles I did not care that I meanwhile changed my desktop Kodi to the nightly! It was really my mistake but as I told the problem is clearly available all with my Kodi instances, what is far more then the mentioned desktop one. On all of my Kodi instances with different devices the problem is clearly the same what is more than suspicious.

But as your catch that the mentioned Kodi instance was really a nightly one I made new test just to show you what is the reality (and at that point I really have to point on that I made really very lot of detailed tests, so my reports are far from some superficial 'drop an instant and false bug report' lines without any real background...).

Here are your data:

Fresh stable Kodi - Matrix on Ubuntu desktop without any specialties as I deleted my whole config dir. to fully reset the app. There is no more personally enabled plugins except Google Drive plugin itself. So the environment is as sterile as it could be. There are 2 files. Both of them are the very same. One on my local drive and the other one is on Google drive. Both of them are 1-1 .MKV video files with 1-1 corresponding Hungarian subtitles.

The currently applied filename structure is:

a b c d e (1234) [h264 1080p • DD 5.1].MKV a b c d e (1234) [h264 1080p • DD 5.1].HU.SRT

The same construction from local drive is fine, while from Google Drive it could not load the subtitle 'sidecar' file. The only differences between the 2 situations is the host. Local drive or Google Drive (through your plugin).

Please check my logs, maybe could help. As I wrote the situation is simply reproducible, I can do it anywhere with any type of Kodi. Checked it, so the test for you could be not more then 5 min.

I happily report the bug to Kodi if you really sure that it is the problem of that but really interesting that the same movie (files(s)) from local drive is perfect while through Google Dive is not. Could be maybe an issue of where Kodi temporary cache the corresponding subtiltes? Could it be that: subtitles from local drive maybe are not cached, while from Google Drive are cached and because of some reason with some filename construction it could not read/write the corresponding cache? Maybe. But for first sight it is really seems to be relevant to the Google Drive plugin.

Here is the log: kodi.log

Please help me on it, if need I will 'forward' the whole thread to Kodi devs.

Thanks again your time!

[cguZZman]

Okay, will take another look once I have some time.