[RELEASE] Missing Movie Plugin - Find Movies and TV Shows that are not in the library

2.1.3a worked the first time. It found a non added movie. it was "sample.m4v". I deleted it. Re ran MMV 2.1.3a and get a script failed error again.

http://pastebin.com/qF6L1igX

(2012-03-15 02:00)mrfatboy Wrote:  2.1.3a worked the first time. It found a non added movie. it was "sample.m4v". I deleted it. Re ran MMV 2.1.3a and get a script failed error again.

This should fix it.

Changelog for 2.1.3b:

• Fixed: Output the right missing list to the log (fixes crash when there is nothing missing)
  

Download

Great! it seems to be working now! Nice Job!

Well, I tried to reproduce that "case"-problem on my Windows notebook and it is easy reproducable. Sorry, I have to say that your current version does not work for me when using different cases.
As said some days ago, the problem is not limited to the hostname. The whole source path is affected. So trial-and-error the hostname does not cut it I think.

Also, is it needed to try both case versions here? It probably does not matter on Windows and on Linux the case of the input 'path' parameter should be the correct one anyway:

I just realized that I did not post the source code of version I made that used an case-insensitive version of 'startswidth'. I think thats the only trick needed to fix the case problem. For me that approach works nicely. Also it is not a problem when finding the actual movies as I formerly thought cause the JSON RPC calls will response with a correct case'd path.

Feel free to correct me where I am wrong, thats just what I have in mind currently...

Also here is my version from some days ago. Maybe you want use parts of it in your version so we dont need to have two different branches.

(2012-03-15 22:08)devkid Wrote:  Well, I tried to reproduce that "case"-problem on my Windows notebook and it is easy reproducable. Sorry, I have to say that your current version does not work for me when using different cases.
As said some days ago, the problem is not limited to the hostname. The whole source path is affected. So trial-and-error the hostname does not cut it I think.

Also, is it needed to try both case versions here? It probably does not matter on Windows and on Linux the case of the input 'path' parameter should be the correct one anyway:

Code:

json = '{"jsonrpc": "2.0", "method": "Files.GetDirectory", "params":{"directory": "' + path + u'"},  "id": 1}'
        result = eval(xbmc.executeJSONRPC(json.encode('utf-8')))
        if 'result' not in result:
            json = '{"jsonrpc": "2.0", "method": "Files.GetDirectory", "params":{"directory": "' + swapcase_hostname(path) + u'"},  "id": 1}'
            result = eval(xbmc.executeJSONRPC(json.encode('utf-8')))

I think when the wrong case is requested the JSON-RPC request will fail on the XBMC side with an argument error, don't know for sure right now though and don't have the time to test it.

(2012-03-15 22:08)devkid Wrote:  I just realized that I did not post the source code of version I made that used an case-insensitive version of 'startswidth'. I think thats the only trick needed to fix the case problem. For me that approach works nicely. Also it is not a problem when finding the actual movies as I formerly thought cause the JSON RPC calls will response with a correct case'd path.

Feel free to correct me where I am wrong, thats just what I have in mind currently...

Also here is my version from some days ago. Maybe you want use parts of it in your version so we dont need to have two different branches.

I'll have a look at it when I have the time, which will probably be next tuesday or wednesday. The case-insensitive startswith looks good to me.

EDIT: One more thing, did you try this with a TV source or a movie source, because I just saw I forgot to add the code to get_tv_sources
EDIT2: Okay, just tested even though I should really be going to sleep. The case-insensitive verion of startswith doesn't work for me, the GetDirectory returns the path like it was requested, thus the library files differ in case from the get_files and you just get a list of every movie on the source.

(2012-03-16 00:25)Sentir101 Wrote:  

(2012-03-15 22:08)devkid Wrote:  Also, is it needed to try both case versions here? It probably does not matter on Windows and on Linux the case of the input 'path' parameter should be the correct one anyway:

I think when the wrong case is requested the JSON-RPC request will fail on the XBMC side with an argument error, don't know for sure right now though and don't have the time to test it.

Sorry I was unclear I guess:
-I think on Windows it wont matter anyway when searching for the actual files.

-But on Linux I think it is not possible to add a source to XBMC that is using the wrong case in the first place. So I guess that on Linux all source strings in XBMC will have the correct case anyway. So you will never get wrong-case'd source strings in the python script. So nothing to worry about here.

-That would mean that the only place where you had to worry about cases would be on Windows in the function that finds the sources using 'startswidth'. When that 'startswidth' is case-insensitive, all should be fine. Thats at least my thinking currently...

(2012-03-16 00:25)Sentir101 Wrote:  EDIT: One more thing, did you try this with a TV source or a movie source, because I just saw I forgot to add the code to get_tv_sources

I did try with a movie source. I think its quite logical that it does not work because that strings wont match even if you correct the hostname:
smb://opteron185/films/
vs
smb://OPTERON185/Films/

Films <-> films

(2012-03-16 00:34)devkid Wrote:  

(2012-03-16 00:25)Sentir101 Wrote:  

(2012-03-15 22:08)devkid Wrote:  Also, is it needed to try both case versions here? It probably does not matter on Windows and on Linux the case of the input 'path' parameter should be the correct one anyway:

I think when the wrong case is requested the JSON-RPC request will fail on the XBMC side with an argument error, don't know for sure right now though and don't have the time to test it.

Sorry I was unclear I guess:
-I think on Windows it wont matter anyway when searching for the actual files.

-But on Linux I think it is not possible to add a source to XBMC that is using the wrong case in the first place. So I guess that on Linux all source strings in XBMC will have the correct case anyway. So you will never get wrong-case'd source strings in the python script. So nothing to worry about here.

-That would mean that the only place where you had to worry about cases would be on Windows in the function that finds the sources using 'startswidth'. When that 'startswidth' is case-insensitive, all should be fine. Thats at least my thinking currently...

Yeah, as you can see in my second edit of the last post, it does matter when searching for the files. The only solution I see here would be to use a case insensitive version of the list.difference function. Oh, and while unlikely the string_startswith_case_insensitive function could have unintended side effects on Linux(/case-sensitive OSes) when someone has two of the same sources only with a different case (so, one would actually be a different directory). Or I'm looking at it the wrong way, that's of course totally possible.

(2012-03-15 22:08)devkid Wrote:  

(2012-03-16 00:25)Sentir101 Wrote:  EDIT: One more thing, did you try this with a TV source or a movie source, because I just saw I forgot to add the code to get_tv_sources

I did try with a movie source. I think its quite logical that it does not work because that strings wont match even if you correct the hostname:
smb://opteron185/films/
vs
smb://OPTERON185/Films/

Films <-> films

Yeah, I should have paid more attention while reading the log because I didn't notice that..

(2012-03-16 01:07)Sentir101 Wrote:  Yeah, as you can see in my second edit of the last post, it does matter when searching for the files. The only solution I see here would be to use a case insensitive version of the list.difference function.

Hm, strange, for me it seemed to work though. Maybe my test was somehow bad. I will test again at the weekened and will try to find out the details.
Yeah a case-insensitive 'difference' would be the ultimate solution but I believe it does not exist. I have one other idea in mind that I will try out. Might be a stupid idea in the first place. Lets see.

(2012-03-16 01:07)Sentir101 Wrote:  Oh, and while unlikely the string_startswith_case_insensitive function could have unintended side effects on Linux(/case-sensitive OSes) when someone has two of the same sources only with a different case (so, one would actually be a different directory). Or I'm looking at it the wrong way, that's of course totally possible.

Right right, I am aware of that. We talked about that some days ago I believe and we agreed that it is an acceptable flaw? I doubt any sane person is using identical file or directory names that only differ in cases. To solve this it would mean you would have to use different code pathes to handle it on case-sensitive and case-insenstivie OSs. But its not worth it I think.

So I will surely play around with it at the weekend so I will report back...

Wow, never got the e-mail the thread was updated ... sorry Sentir101, for not posting the log you asked for. Tried 2.1.3b and it works fine for me now. Although I must say I have a new server now and this time I paid special attention to the file paths. Thanks!

I investigated the case problem a bit and it is as you said: When calling GetDirectory you get the same path as you put in. So I changed it to just put the correct case'd version in so no further correction needed.
When searching for sources I think it is sufficient to use the case insensitive startswith version.

Changes 2.1.3c-devkid:
-fixed case problem (hopefully for real)
-fixed problem with stacked sources

Download

PS.
Is it me or is it not longer possible to attach files to posts?