Kodi Community Forum

(2014-12-08, 15:50)Zacharybinx34 Wrote: [ -> ]Can anyone help me with recommending what settings I should use if I want to avoid the long populating/updating that occurs every time I open ptvl?

Thanks

What's your setup?

(2014-12-08, 16:14)Ovokx Wrote: [ -> ]try updating once a week

That's what I'd like, but it does it everytime I open the program. Any ideas how to stop this?

(2014-12-08, 19:47)Zacharybinx34 Wrote: [ -> ]

(2014-12-08, 16:14)Ovokx Wrote: [ -> ]try updating once a week

That's what I'd like, but it does it everytime I open the program. Any ideas how to stop this?

Yeah go to the "General" tab in the settings and change the time between channel updates to weekly. It's self-explanatory.

(2014-12-08, 19:50)Marshall Wrote: [ -> ]

(2014-12-08, 19:47)Zacharybinx34 Wrote: [ -> ]

(2014-12-08, 16:14)Ovokx Wrote: [ -> ]try updating once a week

That's what I'd like, but it does it everytime I open the program. Any ideas how to stop this?

Yeah go to the "General" tab in the settings and change the time between channel updates to weekly. It's self-explanatory.

/facepalm

thanks

(2014-12-08, 19:53)Zacharybinx34 Wrote: [ -> ]/facepalm

thanks

On a side note, I donated like 2 months ago, never received a donor login.

I seem to have problems with rtmp streams using liveTV (channel type 8) channels. These types of streams aren't listed in the epg. HSN is an example of this type of stream. Didn't wanna post details as am not sure on rules on it. Please advise. Log will be posted if needed.

Edit: Seems that changing those streams from rtmp to rtsp seems to make those channels work.

Edit: RTMP streams don't seem to work with channel type 9 streams either. Help Luna!

(2014-12-08, 19:56)Marshall Wrote: [ -> ]

(2014-12-08, 19:53)Zacharybinx34 Wrote: [ -> ]/facepalm

thanks

I made it weekly, but when I start PTVL I still get "Updating Channels".

(2014-12-08, 20:48)Zacharybinx34 Wrote: [ -> ]

(2014-12-08, 19:56)Marshall Wrote: [ -> ]

(2014-12-08, 19:53)Zacharybinx34 Wrote: [ -> ]/facepalm

thanks

I made it weekly, but when I start PTVL I still get "Updating Channels".

But is it taking as long? That's what you originally asked.

(2014-12-08, 20:59)Marshall Wrote: [ -> ]

(2014-12-08, 20:48)Zacharybinx34 Wrote: [ -> ]

(2014-12-08, 19:56)Marshall Wrote: [ -> ]

I made it weekly, but when I start PTVL I still get "Updating Channels".

But is it taking as long? That's what you originally asked.

Nope, I guess not, thanks!

I recently upgrade to 0.5.6c and I gotta say this addon has improved dramatically in both stability and featureset over the last couple of month, great work Luna, very impressive.
Code related question for you Luna, in FileAccess.py, what is the intent of the refreshLocks method? I've been having a strange issue on my FireTVs and I think it's related to that method. Long story short, my system works great for a seemingly random period of time and then it becomes unstable and can't play any videos either via PSTVL or direct launching. Any attempts to play a video just bring up the XBMC loading indicator and the video never starts (no buffering, just never starts). Checking the log shows that the request to start the video happens, but it just doesn't start.
After some digging, I believe on the FireTVs that the refreshLocks method is spinning up threads that never return and eventually there aren't enough system threads available to even start up a video which is why I spin like this. Restarting XBMC (not the whole FireTV) temporarily solves the issue. A couple of weeks ago I put a return statement at the top of the refreshLocks method so that the refreshLocksTimer doesn't get reset and no more threads get spun up. This has solved my issue and my system is good to go, or at least appears to be. I'm curious what this method is for and if I may have caused downstream side effects that I haven't noticed yet. Thanks!

(2014-12-09, 16:24)windsorguy1979 Wrote: [ -> ]I recently upgrade to 0.5.6c and I gotta say this addon has improved dramatically in both stability and featureset over the last couple of month, great work Luna, very impressive.
Code related question for you Luna, in FileAccess.py, what is the intent of the refreshLocks method? I've been having a strange issue on my FireTVs and I think it's related to that method. Long story short, my system works great for a seemingly random period of time and then it becomes unstable and can't play any videos either via PSTVL or direct launching. Any attempts to play a video just bring up the XBMC loading indicator and the video never starts (no buffering, just never starts). Checking the log shows that the request to start the video happens, but it just doesn't start.
After some digging, I believe on the FireTVs that the refreshLocks method is spinning up threads that never return and eventually there aren't enough system threads available to even start up a video which is why I spin like this. Restarting XBMC (not the whole FireTV) temporarily solves the issue. A couple of weeks ago I put a return statement at the top of the refreshLocks method so that the refreshLocksTimer doesn't get reset and no more threads get spun up. This has solved my issue and my system is good to go, or at least appears to be. I'm curious what this method is for and if I may have caused downstream side effects that I haven't noticed yet. Thanks!

If you don't mind me asking... what makes you believe this has anything to do with your problem? other then you see a print of it on your log? Just wondering...

Anyway, refreshLock doesn't call new threads, then abandon them. It's only called once, and doesn't run more then one thread.

(2014-12-09, 18:20)Lunatixz Wrote: [ -> ]

(2014-12-09, 16:24)windsorguy1979 Wrote: [ -> ]I recently upgrade to 0.5.6c and I gotta say this addon has improved dramatically in both stability and featureset over the last couple of month, great work Luna, very impressive.
Code related question for you Luna, in FileAccess.py, what is the intent of the refreshLocks method? I've been having a strange issue on my FireTVs and I think it's related to that method. Long story short, my system works great for a seemingly random period of time and then it becomes unstable and can't play any videos either via PSTVL or direct launching. Any attempts to play a video just bring up the XBMC loading indicator and the video never starts (no buffering, just never starts). Checking the log shows that the request to start the video happens, but it just doesn't start.
After some digging, I believe on the FireTVs that the refreshLocks method is spinning up threads that never return and eventually there aren't enough system threads available to even start up a video which is why I spin like this. Restarting XBMC (not the whole FireTV) temporarily solves the issue. A couple of weeks ago I put a return statement at the top of the refreshLocks method so that the refreshLocksTimer doesn't get reset and no more threads get spun up. This has solved my issue and my system is good to go, or at least appears to be. I'm curious what this method is for and if I may have caused downstream side effects that I haven't noticed yet. Thanks!

If you don't mind me asking... what makes you believe this has anything to do with your problem? other then you see a print of it on your log? Just wondering...

Anyway, refreshLock doesn't call new threads, then abandon them. It's only called once, and doesn't run more then one thread.

Debugging by guessing . refreshLocks is the only thing active in my logs when this issue starts and returning False right away was the only change I made and seems to have solved my issue. Python isn't my bread and butter but I was looking at "self.refreshLocksTimer = threading.Timer(4.0, self.refreshLocks)" and thinking that was spinning up a new thread but not seeing anything to kill the old thread. I just re-read the timer API that while it is true that it is starting a new thread, the old thread stops when refreshLocks ends. Looking at this now, I'm not sure why this change seems to have corrected my problem. What is this method for anyhow? Not looking for a fix in the codebase, this might be a one-off that I run on my system that works for me for some reason.

(2014-12-09, 20:20)windsorguy1979 Wrote: [ -> ]

(2014-12-09, 18:20)Lunatixz Wrote: [ -> ]

(2014-12-09, 16:24)windsorguy1979 Wrote: [ -> ]I recently upgrade to 0.5.6c and I gotta say this addon has improved dramatically in both stability and featureset over the last couple of month, great work Luna, very impressive.
Code related question for you Luna, in FileAccess.py, what is the intent of the refreshLocks method? I've been having a strange issue on my FireTVs and I think it's related to that method. Long story short, my system works great for a seemingly random period of time and then it becomes unstable and can't play any videos either via PSTVL or direct launching. Any attempts to play a video just bring up the XBMC loading indicator and the video never starts (no buffering, just never starts). Checking the log shows that the request to start the video happens, but it just doesn't start.
After some digging, I believe on the FireTVs that the refreshLocks method is spinning up threads that never return and eventually there aren't enough system threads available to even start up a video which is why I spin like this. Restarting XBMC (not the whole FireTV) temporarily solves the issue. A couple of weeks ago I put a return statement at the top of the refreshLocks method so that the refreshLocksTimer doesn't get reset and no more threads get spun up. This has solved my issue and my system is good to go, or at least appears to be. I'm curious what this method is for and if I may have caused downstream side effects that I haven't noticed yet. Thanks!

If you don't mind me asking... what makes you believe this has anything to do with your problem? other then you see a print of it on your log? Just wondering...

Anyway, refreshLock doesn't call new threads, then abandon them. It's only called once, and doesn't run more then one thread.

Debugging by guessing . refreshLocks is the only thing active in my logs when this issue starts and returning False right away was the only change I made and seems to have solved my issue. Python isn't my bread and butter but I was looking at "self.refreshLocksTimer = threading.Timer(4.0, self.refreshLocks)" and thinking that was spinning up a new thread but not seeing anything to kill the old thread. I just re-read the timer API that while it is true that it is starting a new thread, the old thread stops when refreshLocks ends. Looking at this now, I'm not sure why this change seems to have corrected my problem. What is this method for anyhow? Not looking for a fix in the codebase, this might be a one-off that I run on my system that works for me for some reason.

It's part of channel sharing and file locking... it runs once, every 4 minutes as designed. If you could send me a log when you experience your problem I could provide further input.

(2014-12-09, 20:44)Lunatixz Wrote: [ -> ]

(2014-12-09, 20:20)windsorguy1979 Wrote: [ -> ]

(2014-12-09, 18:20)Lunatixz Wrote: [ -> ]If you don't mind me asking... what makes you believe this has anything to do with your problem? other then you see a print of it on your log? Just wondering...

Anyway, refreshLock doesn't call new threads, then abandon them. It's only called once, and doesn't run more then one thread.

Debugging by guessing . refreshLocks is the only thing active in my logs when this issue starts and returning False right away was the only change I made and seems to have solved my issue. Python isn't my bread and butter but I was looking at "self.refreshLocksTimer = threading.Timer(4.0, self.refreshLocks)" and thinking that was spinning up a new thread but not seeing anything to kill the old thread. I just re-read the timer API that while it is true that it is starting a new thread, the old thread stops when refreshLocks ends. Looking at this now, I'm not sure why this change seems to have corrected my problem. What is this method for anyhow? Not looking for a fix in the codebase, this might be a one-off that I run on my system that works for me for some reason.

It's part of channel sharing and file locking... it runs once, every 4 minutes as designed. If you could send me a log when you experience your problem I could provide further input.

That may be why I'm seeing so many of these in my log file and why it may be bogging down my FireTVs. Looking at the Timer API, the interval '4.0' is 4 seconds, not 4 minutes, correct? Which means refreshLocks is running every 4 seconds. I'm looking at this for reference: https://docs.python.org/2/library/thread...er-objects