search

virdaus / xot-uzg

Automatically exported from code.google.com/p/xot-uzg
0 stars 0 forks source link

UZG Cache not cleaned #478

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 

What channel are you trying to watch?
UZG

What episode are you trying to watch?
Any

What steps will reproduce the problem?
1. Use UZG with caching enabled (cleanup after 1 day)
2. Eventually storage will fill up. Even though some files are older than 1 
day. XBMC UI will hang, 
3. Remove file through SSH and reboot to start again.

What version of XBMC are you using? On what operating system?
Openelec 3.2.3 on RPi model B 512MB. storage on 2GB USB thumb drive.
XOT 3.3.7

Please provide any additional information below.
Started XOT in the evening of October 28th. Watched one episode succesfully, 
hang while downloading the second episode. Logs show no cache cleanup on 
October 28m just one in the whole log on October 26th.
Files in cache from October 25th and two from October 27th afternoon.
After a reboot and trying to play the same episode cache still not cleaned. 
Playing fails.

Please ATTACH a complete DEBUG uzg.log or uzgplugin.log and add an
xbmc.log. Without a logfile issues cannot be fixed. Wondering where
you can get them? Read it here:
http://www.rieter.net/content/xot/troubleshooting/#Log_level_settings

Original issue reported on code.google.com by Peter.Oo...@gmail.com on 28 Oct 2013 at 8:18

Attachments:

GoogleCodeExporter commented 8 years ago 
Strange. Could you give me a listing of the 
/storage/.xbmc/userdata/addon_data/net.rieter.xot/cache/ path, including 
modified dates?

Original comment by basrie...@gmail.com on 28 Oct 2013 at 9:12

GoogleCodeExporter commented 8 years ago 
Thanks for the quick response. 
I already deleted the ..mp4 files ( they have indeed two dots before the mp4 
extension), but the corresponding .srt files with the same modified date are 
still there. I uploaded a screenshot.

BTW I start uitzendinggemist from an XBMC favorite. Does that bypass the cache 
cleanup?

Original comment by Peter.Oo...@gmail.com on 28 Oct 2013 at 10:02

Attachments:

GoogleCodeExporter commented 8 years ago 
Ok, there is no issue here. We have 2 different caches: XOT cache and UZG 
cache. The former is used for the HTTP cache (subfolder www) and other cache 
files like subtitles (srt). The latter is just for UZG downloads.

Apparently you configured the UZG cache path to be equal to the generic XOT 
cache path (/storage/.xbmc/userdata/addon_data/net.rieter.xot/cache/). The UZG 
cleanup does it's work, as there are not UZG files left (they all start with 
"xot."). The files remaining are the generic cache files, which will expire 
after 7 days hours (not configurable). 

So don't worry. It's all working as expected.

Original comment by basrie...@gmail.com on 28 Oct 2013 at 10:38

GoogleCodeExporter commented 8 years ago 
I do not really understand. The problem was with the xot*..mp4 files that 
filled up the USB drive.
Those I had to delete by hand. They were there, with dates much older than 1 
day. I will point the UZG cache to another folder and see if that improves 
things.

Original comment by Peter.Oo...@gmail.com on 28 Oct 2013 at 10:51

GoogleCodeExporter commented 8 years ago 
Ok, keep mind that only if you completely start XOT-Uzg.v3 from scratch the 
clean up of the cache happens. 

If you use favourites,  run it from a shortcut on the home screen or never exit 
the add-on it will never clean up. 

We made that decision to improve performance. If you want to verify this, start 
XOT-Uzg.v3 from the video -> add-ons list. Then it will always start from 
scratch. 

Perhaps we should change this behaviour. Let me know your findings.

Original comment by basrie...@gmail.com on 28 Oct 2013 at 11:05

GoogleCodeExporter commented 8 years ago 
I watched some extra episodes until the USB drive mounted as storage was almost 
full. The next day I started XOT from Videos>add-ons, and this time the cache 
was cleaned as it should. So starting from a favorite seemed to be my main 
problem.

However, XBMC still became unresponsive after the new download was finished, 
but this time apparently not due to /storage being full. Not sure what is the 
problem though. The downloading progress bar disappeared and then nothing. SSH 
was available, but XBMC did not respond, or play the downloaded file for that 
matter.

Original comment by Peter.Oo...@gmail.com on 31 Oct 2013 at 10:08

Attachments:

GoogleCodeExporter commented 8 years ago 
Ok, I will see if I can revise the way I determine when to cleanup the cache.

Regarding the crash: xbmc.old.log does not contain any info on XOT playback. So 
I guess it is the wrong log?

Original comment by basrie...@gmail.com on 1 Nov 2013 at 10:14

GoogleCodeExporter commented 8 years ago 
The xbmc.old.log was the log when XBMC froze. The new one just started after I 
rebooted the RPi.
Until now the freezing coincided with the USB drive being full, but this time 
the cache was just cleaned minutes before. 
When I find out how I can reproduce the freezing I will turn on XBMC debugging 
beforehand. 
Thanks for the help.

Original comment by Peter.Oo...@gmail.com on 1 Nov 2013 at 10:26

GoogleCodeExporter commented 8 years ago 
I changed the logic for cleaning up now. It should also work with favorites. It 
will be in the next version. If you find the problem with the streams and 
freezing, please let me know.

Original comment by basrie...@gmail.com on 7 Nov 2013 at 9:58

GoogleCodeExporter commented 8 years ago 
Excellent! That will make my live a little bit easier again. Starting from 
Favorites definitely improves the WAF.

I had not experienced the freeze again, but I was able to provoke it this 
morning. 

I started XOT from Video-Add-ons and went to uitzendinggemist.nl-top50.
Selected Reporter from Nov. 7th, selected Play and it started downloading to 
cache and playing correctly.
Using Cyberduck I noticed a three day old file was cleaned from the cache, but 
a file from last night (correctly) remained.
I stopped the video and selected the same episode again, which downloaded to 
the cache again completely, after which XBMC froze.
In the cache there were two seemingly identical files which both played OK on 
my PC. df -h showed there was still 200+ MB available on /Storage.

Unfortunately no errors in the xbmc.log even though debug logging was on.

An ideas?

Original comment by KoeKan...@gmail.com on 8 Nov 2013 at 10:08

Attachments:

GoogleCodeExporter commented 8 years ago 
I see my son was logged in, but the 'koekanaal'-response was actually from me.

Peter

Original comment by Peter.Oo...@gmail.com on 8 Nov 2013 at 10:10

GoogleCodeExporter commented 8 years ago 
The freeze seems weird, as XBMC does show a deinit of the progress dialog 
(------ Window Deinit (DialogProgress.xml) ------) but none of the logs show 
the playback. So it is hard to detect. 

But I must also say that those NOS streams just are not being handled nicely in 
XBMC 12.x. I am really hoping for improvements in XBMC 13.x.

Original comment by basrie...@gmail.com on 8 Nov 2013 at 10:52

GoogleCodeExporter commented 8 years ago

Original comment by basrie...@gmail.com on 26 Nov 2013 at 5:19