Patch for /trunk/plugin.video.iplayer/default.py

[GoogleCodeExporter]

I believe this might be an appropriate change to address issue 115.

Original issue reported on code.google.com by cjbarnes18 on 24 Jul 2013 at 10:21

Attachments:

• default.py.patch

[GoogleCodeExporter]

Any reason why you didnt add it to issue 115 ? :) ill check though thanks.

Original comment by exob...@gmail.com on 25 Jul 2013 at 12:10

[GoogleCodeExporter]

sorry, this was my 1st use of google code for patch submission :-s

Original comment by cjbarnes18 on 25 Jul 2013 at 2:29

[GoogleCodeExporter]

Thanks for the patch :) 

However, this approach will not work. XBMC calls the python file every time you 
browse content from the plugin. The reason for having the lock file in the 
first place is that it is possible to start playback and then go back later and 
navigate the plugin structure, and possibly request a new playback. This would 
result in a second thread being started without the old thread being stopped, 
which causes problems when trying to determine where the resume point for the 
old programme should be. Your patch would delete the lock file when the user 
requested any new content from the plugin, allowing the second thread to be 
started.

I agree that a solution is needed however; the lock file cannot be cleared 
reliably when there is an exception (connection error, crash etc) which causes 
problems. Perhaps adding text on how to force the removal of the lock file to 
the error message shown.

Original comment by alastair...@gmail.com on 26 Jul 2013 at 11:02

[GoogleCodeExporter]

Would it be possible to detect whether the lock file refers to a valid object, 
if so we could invalidate it automatically where appropriate instead?

Original comment by cjbarnes18 on 26 Jul 2013 at 10:17

[GoogleCodeExporter]

Hi

Can you explain the action of the lock file here please ? 

It appears that whilst XBMC player is playing, the lock file carries the name 
of the object, and at the same time outputs the current play position every few 
seconds so that you know where to resume from.

That I get.   But, if I stop the video, the resume point is updated, and, 
ideally, the lock file removed.

It seems that if the playback is not stopped by the user but by some other 
reason, that is where we get into an issue of the lock file being held.

So, what is wrong with putting the playback into a "while" loop and checking 
"xbmc.isPlaying()" and then ALWAYS deleting the lock file if this comes back as 
false ?

Or have I (and this is perfectly possible) totally missed the point here !!!!

{BTW, this is a royal PITA for those of us in <ahem> remote locations with 
undeveloped Internet infrastructure.   Loss of BBC iPlayer would be number 1 
reason for us to move back home.}

{Another BTW - this app is a life-saver for us - had we not been able to watch 
proper TV or listen to proper radio, we'd have turned round and come straight 
back.}

Original comment by dlake...@gmail.com on 29 Jul 2013 at 10:38

[GoogleCodeExporter]

Hi,

Unfortunately I won't have access to the iPlayer streams for testing for a week 
or so. So what follows is going on my memory of development at the time. 
Hopefully I'll find some time then to look at this, or perhaps you can confirm 
the below behaviour in the mean time.

When playing a stream, it is possible to open up the plugin menu system and 
attempt to start a new stream. This occurs in a different thread to the first 
that is currently checking the resume point. My memory is that xbmc.isPlaying() 
returns FALSE in the second thread, even though playback is occurring in the 
first. Therefore, the lock file is needed to provide this flag across the two 
threads.

As you mention, the lock file will not be deleted if playback is stopped due to 
an error condition (e.g. connection failure). This is because XBMC does not 
trigger the onStop callback in this situation (it is only called on manual 
stop).

I'm happy to hear about a more robust way of handling this threading problem or 
the 'XBMC' way of handling the playback error condition; my knowledge in this 
area is not great. If we can't find a way, then the best option is probably to 
provide an addon option to disable the resume functionality.

Original comment by alastair...@gmail.com on 1 Aug 2013 at 3:50

[GoogleCodeExporter]

Have a look at my patch for issue 115.  So far, this has proved robust for 
me....

Original comment by dlake...@gmail.com on 1 Aug 2013 at 11:08

[GoogleCodeExporter]

Had a chance to test and it seems I was wrong. Have taken and committed your 
approach to removing stale lock files - it's in the latest revision.

Original comment by alastair...@gmail.com on 5 Aug 2013 at 11:06

• Changed state: Fixed