2014-01-13, 01:23
can you give a rundown of your hardware specs, OS, recorded TV drive (type, capacity, free space) and network connection? Is it server and client on one box or on separate PCs? If separate list details of both.
2014-01-13, 01:48
Windows 7 32bit, 4Gb memory, 500Gb HD for recordings with 56Gb free, Gigabit Ethernet with a fixed IP address. XBMC, WMC and ServerWMC are all on the same machine. AMD Phenom II X4 925 processor. Antivirus disabled on recording drive.
.
.
2014-01-13, 01:57
This happened to me last night during the Pats game with my in-laws visiting. Maybe XBMC just doesn't like football!
One other possibility is the memory leak that was discussed a couple of months ago. There appears to be a gradual memory leak during Live TV in XBMC. The memory used by XBMC.exe grows and grows and is never released. Presumably XBMC would crash when it gets to a certain size.
Edit: probably not this. Wouldn't happen within 15-20 minutes. Would take many hours.
One other possibility is the memory leak that was discussed a couple of months ago. There appears to be a gradual memory leak during Live TV in XBMC. The memory used by XBMC.exe grows and grows and is never released. Presumably XBMC would crash when it gets to a certain size.
Edit: probably not this. Wouldn't happen within 15-20 minutes. Would take many hours.
2014-01-13, 04:11
holy cow, your ServerWMC log files are massive!
It looks like you have the Log All WTV Headers debug option on. This is a very low level debug option that writes out huge amounts of stuff to the logfile. Infact, the sheer volume of this logging could very well be impacting the performance of ServerWMC remuxing the WTV to TS. In theory at least, this could possibly cause XBMC to crash (although that's a bit of a stretch, obviously nothing we do should be able to crash XBMC)
In hindisght I think it was a mistake to have this debug option have it's own checkbox on the GUI, as people are then probably tempted to tick it, particularly if they are having problems and trying anything!
Can you please turn that debug option off? Perhaps it isnt contributing to the problem, but it is definitely something that shouldnt be on for normal use and also means that any future logfiles you upload for us wont be so large and will be more able to be read/analysed by us mere humans
It looks like you have the Log All WTV Headers debug option on. This is a very low level debug option that writes out huge amounts of stuff to the logfile. Infact, the sheer volume of this logging could very well be impacting the performance of ServerWMC remuxing the WTV to TS. In theory at least, this could possibly cause XBMC to crash (although that's a bit of a stretch, obviously nothing we do should be able to crash XBMC)
In hindisght I think it was a mistake to have this debug option have it's own checkbox on the GUI, as people are then probably tempted to tick it, particularly if they are having problems and trying anything!
Can you please turn that debug option off? Perhaps it isnt contributing to the problem, but it is definitely something that shouldnt be on for normal use and also means that any future logfiles you upload for us wont be so large and will be more able to be read/analysed by us mere humans
2014-01-13, 14:53
No problem. Will turn it off and see if I can replicate tonight!
2014-01-13, 16:19
Just uploaded the latest example of vidoe going from good playback to extremely slow playback.
2014-01-13, 17:46
I don't see this newest file yet, but I looked at the first ones you sent up. I set them to be remuxed while I viewing hoping to simulate the same situation as you and see a crash, but it behaved fine - xbmc just played them to the end. Really I am at a loss as to why its crashing, or really how a stream can crash xbmc at all. In my development I have experimented with sending xbmc some really f*'d up streams and it never chashes, it just stops.
Is this a pure vanilla version of xbmc? Any weird codecs installed or third party apps on the system that could have an effect?
Do you keep xbmc running all the time on an always on system? Can you monitor your memory usage?
I forgot to mention, in your honor I watch 6 hours of football yesterday, I really didn't want to watch that much - I just figured I needed to test
Is this a pure vanilla version of xbmc? Any weird codecs installed or third party apps on the system that could have an effect?
Do you keep xbmc running all the time on an always on system? Can you monitor your memory usage?
I forgot to mention, in your honor I watch 6 hours of football yesterday, I really didn't want to watch that much - I just figured I needed to test
2014-01-13, 18:51
Pure vanilla XBMC. A later nightly Gotham build (within a few days of the latest). Should I use a different build? I have TVersity installed on the machine but rarely used. No codec packages are installed.
One time this morning before I when to work, I was watching Live TV. Playback stop, XBMC minimized itself. When I restarted, the skin had changed back to Confluence (from MQ5), LIveTV was disabled and BoblightD was nolonger installed.
Right now the slowdown in playback is quite repeatable. It seems that only requires stopping playback and reselecting the channel. Perhaps the slow playback and XBMC crashes are related?
XBMC is usually only running when I am there but since I have been trying to troubleshoot it, I have left it running full time. Will check memory consumption nexst time
One time this morning before I when to work, I was watching Live TV. Playback stop, XBMC minimized itself. When I restarted, the skin had changed back to Confluence (from MQ5), LIveTV was disabled and BoblightD was nolonger installed.
Right now the slowdown in playback is quite repeatable. It seems that only requires stopping playback and reselecting the channel. Perhaps the slow playback and XBMC crashes are related?
XBMC is usually only running when I am there but since I have been trying to troubleshoot it, I have left it running full time. Will check memory consumption nexst time
2014-01-13, 19:31
That behavior of playback stopping, minimizing itself and changing the skin is freaking weird. Does the xbmc log tell you what happened here?
Did you hand install pvr.wmc or get it from the gotham nightly?
I can't make the slowdown happen on my end, I am running an older version of gotham.
BoblightD?
Did you hand install pvr.wmc or get it from the gotham nightly?
I can't make the slowdown happen on my end, I am running an older version of gotham.
BoblightD?
2014-01-14, 01:27
Here are some random ramblings from me
If you are using Gotham nightlies (ie Alpha releases) it's always worth keeping that in mind, it wouldnt be the first time that weird alpha/nightly issues are contributing to things. You could try running older and newer nightlies as well as a troubleshooting step. You could also list the precise nightly, so krusty or others could attempt to duplicate your exact setup.
Why dont you temporarily try the Frodo XBMC (with correct pvr.wmc addon version for Frodo) and see what happens. That should help narrow down whether the Gotham build is related or if it's a server/remuxing issue
Krusty - I do think in the past when I was mucking around with the remuxer I did manage to crash XBMC but that was potentially by having breakpoints in the server side and all sorts of things... It was a while ago so I really cant be sure though.
The crash is one thing, but "things slowing down" also sounds like it could be worth investigating the angles of storage/processing being impacted etc. Certainly not trying to point fingers and your setup sounds more than adequate (im running mine on a pentium processor, with a ISCSI mounted rec TV drive on a NAS over GB ethernet so yours is far more powerful than my setup!) but just thinking of how we could potentially isolate/troubleshoot things.
Out of interest, Is the recorded TV hard drive dedicated only to recorded TV? do you have anything like SickBeard/CouchPotato or NZB stuff that could be hammering disks while unpacking archive files and things like that?
If you are able to, you might try some different storage arrangements to see if it made a difference (eg a hard drive that wasnt so full, or an SSD for a shotgun approach (not recomending to use an SSD forever, just to see if it made any difference).
You can also take the WTV file and the TS file and try playing them back through XBMC normal video section and see if they play OK. They probably would I guess, although it might be interesting what happens when you get to the very end of the TS file (perhaps it might crash out, like it did when it was watching this TS file as a "LiveTV"). You have uploaded the WTV files but perhaps upload a TS file as well since that is what your remuxer has produced from the WTV file. If krusty has tested remuxing your WTV files and not had the same problem than it seems to indicate that it is something that is happening during remuxing on your PC that is upsetting XBMC, and not something in the WTV file which is reproducible when remuxing that WTV file.
If you dont use PVR function in XBMC does it ever have any lags/slowdowns or hangs?
Do you have another PC/laptop you could run a client on and see if the same problem happens?
Also another option is to setup another PC as the server, with both a local client and using this existing client, and seeing if either of them crash/slowdown. Obviously this is a bit painful as you need to have WMC on the other PC, setup the channels, move your tuner over etc. It depends how far you are willing to go! I guess leave this one until last
Also, we could seek help from actual XBMC developers regarding your error logs. Just looking at the 2 you posted and they show different error messages. The first one had errors loading a shader and creating a video texture, whereas the second one seems to complain about "timeout adding data to renderer".
I (and I assume Krusty) really have no idea about this side of things so we really dont know what is happening. It seems logical to conclude that if it only happens when watching TV it is something in the TS file that could be doing it, but it could be as simple as problems on the backend creating/remuxing the data are causing the frontend (nightly Alpha builf of Gotham) to crash, when Frodo might have handled things more gracefully and just stopped the playback... I am not saying this is the cause, just saying such a situation could be possible, and we need someone who knows what they are looking at to review your XBMC logs and comment.
If you are using Gotham nightlies (ie Alpha releases) it's always worth keeping that in mind, it wouldnt be the first time that weird alpha/nightly issues are contributing to things. You could try running older and newer nightlies as well as a troubleshooting step. You could also list the precise nightly, so krusty or others could attempt to duplicate your exact setup.
Why dont you temporarily try the Frodo XBMC (with correct pvr.wmc addon version for Frodo) and see what happens. That should help narrow down whether the Gotham build is related or if it's a server/remuxing issue
Krusty - I do think in the past when I was mucking around with the remuxer I did manage to crash XBMC but that was potentially by having breakpoints in the server side and all sorts of things... It was a while ago so I really cant be sure though.
The crash is one thing, but "things slowing down" also sounds like it could be worth investigating the angles of storage/processing being impacted etc. Certainly not trying to point fingers and your setup sounds more than adequate (im running mine on a pentium processor, with a ISCSI mounted rec TV drive on a NAS over GB ethernet so yours is far more powerful than my setup!) but just thinking of how we could potentially isolate/troubleshoot things.
Out of interest, Is the recorded TV hard drive dedicated only to recorded TV? do you have anything like SickBeard/CouchPotato or NZB stuff that could be hammering disks while unpacking archive files and things like that?
If you are able to, you might try some different storage arrangements to see if it made a difference (eg a hard drive that wasnt so full, or an SSD for a shotgun approach (not recomending to use an SSD forever, just to see if it made any difference).
You can also take the WTV file and the TS file and try playing them back through XBMC normal video section and see if they play OK. They probably would I guess, although it might be interesting what happens when you get to the very end of the TS file (perhaps it might crash out, like it did when it was watching this TS file as a "LiveTV"). You have uploaded the WTV files but perhaps upload a TS file as well since that is what your remuxer has produced from the WTV file. If krusty has tested remuxing your WTV files and not had the same problem than it seems to indicate that it is something that is happening during remuxing on your PC that is upsetting XBMC, and not something in the WTV file which is reproducible when remuxing that WTV file.
If you dont use PVR function in XBMC does it ever have any lags/slowdowns or hangs?
Do you have another PC/laptop you could run a client on and see if the same problem happens?
Also another option is to setup another PC as the server, with both a local client and using this existing client, and seeing if either of them crash/slowdown. Obviously this is a bit painful as you need to have WMC on the other PC, setup the channels, move your tuner over etc. It depends how far you are willing to go! I guess leave this one until last
Also, we could seek help from actual XBMC developers regarding your error logs. Just looking at the 2 you posted and they show different error messages. The first one had errors loading a shader and creating a video texture, whereas the second one seems to complain about "timeout adding data to renderer".
I (and I assume Krusty) really have no idea about this side of things so we really dont know what is happening. It seems logical to conclude that if it only happens when watching TV it is something in the TS file that could be doing it, but it could be as simple as problems on the backend creating/remuxing the data are causing the frontend (nightly Alpha builf of Gotham) to crash, when Frodo might have handled things more gracefully and just stopped the playback... I am not saying this is the cause, just saying such a situation could be possible, and we need someone who knows what they are looking at to review your XBMC logs and comment.
2014-01-14, 01:41
Up until recently, I had been installing the PVR.WMC addin manually. A few weeks ago, a flushed everything and did a fresh install.
The recordedTV drive is dedicated to WMC. I have not noticed any slowdowns when watching regular videos.
At this point the slow down is reproducible. It is just the amount of time to the problem starting.
I can't quickly create a new machine but my try that next weekend. Swapping drives .is also a good idea. I wil have to cehck and see what I have avaialble.
Both of my tuners are network based (HDHomeRun Classic and an HDHomeRun Prime.
The recordedTV drive is dedicated to WMC. I have not noticed any slowdowns when watching regular videos.
At this point the slow down is reproducible. It is just the amount of time to the problem starting.
I can't quickly create a new machine but my try that next weekend. Swapping drives .is also a good idea. I wil have to cehck and see what I have avaialble.
Both of my tuners are network based (HDHomeRun Classic and an HDHomeRun Prime.
2014-01-14, 01:47
That's good that you have network tuners, at least it makes it easier to move the "server" to another box, temporarily. If you want to try something before the weekend and before you hav eto start building PCs and swapping drives etc, pop the Frodo release on your PC temporarily, and see how that goes. The addon isnt in frodo officially so you'll need to download it and install from zip. Make sure to grab the right one
2014-01-14, 01:51
Just an FYI, you can run both Gotham and Frodo on the same machine (not at the same time) assuming you already have Frodo installed, it will use C:\Users\username\AppData\Roaming\XBMC\userdata as its userdata folder. If you later install Gotham do not install it to Program Files, instead install it to c:\XBMC then when you run Gotham use the -p switch (C:\XBMC\XBMC.exe -p) it will then use C:\XBMC\portable_data as the userdata directory keeping all userdata and addons separate from your first install. If you've already got Gotham installed then you can install and run Frodo with the -p switch.
2014-01-14, 02:23
I will try the portable option tomorrow evening. I have to go curl (that strange sport where you slide 40# stones down the ice) tonight.
