home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Talk
Memory leak in TVService
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Berney" data-source="post: 1285887" data-attributes="member: 168121"><p>Hi everyone, I hope you all had a good weekend.</p><p></p><p>Joecrow, yes it would seem there are differences between Germany and the Uk because there us no data in my provider column.</p><p></p><p>CyberSimian, I absolutely agree with you that it would be useful to </p><p>a) be able to recreate the problem easily so it can be a quality control test.</p><p>And</p><p>B) Narrow down where the problem is occurring as much as possible so that it can be put on a 'to fix' list when someone with the required skills comes along, making their job easier.</p><p></p><p>I've done the following test over the weekend:-</p><p></p><p>As suggested by CyberSimian I changed all the 'Record every time on every channel' (ETEC) instances to 'Record Every time on this channel ' (ETTC). There were 9 occurances. </p><p>I've run the test over the weekend including up till now which is approximately 60 hours. The TVServer no longer locked up. The memory still filled up at around the same rate and up to the same amount full (approximately 1.6 gig). And the server has crashed 3 times, but it was able to restart each time due to windows service settings I have put in (i.e. restart the service in a crash). Where as previously the TVServer locked and was unable to easily restart it easily. So there has been some improvement but its not stopped the problem of a memory leak of some sort occurring.</p><p>Now my next thought is what is the difference between CyberSimian's (CS) testing and my pre-test situation? If I understand CS correctly had the same number of ETEC recordings as I did (9). CS recordings happened successfully and no apparent memory leaks. Now here is the difference as I see it:- </p><p>In my 9 recordings setup none of them occurred (because none of the 9 ETEC recordings were broadcast). So could it be that is the problem that yet to be recorded settings are left in memory and gradually build up till the memory is full ?</p><p>This would seem to fit in with the way I record in general which I will explain. Generally I like to collect recordings not just for what I like to watch but to gather for when family and friends turn up and want to watch that they find interesting from my 'library' that I have built up. Often a friend will say 'hey I've just become interested in a series and I missed the first few episodes'. So I'll put in a scheduled recording for either ETEC or more likely ETTC. Over the years this has built up to many scheduled recordings that might happen say a couple of years in the future or not at all ever. The way I use Mediaportal means there are very many scheduled recordings that rarely get actually recorded, possibly using a lot of memory that some how builds up till it totally fills up.</p><p></p><p>I've been trying to figure out the source code and from what I've deduced so far it would seem to me that the epg is grabbed from a broadcast stream in the file EpgDBUpdater.cs in the procedure 'ImportPrograms'. This is put into the sql database. Checking of is it time to actually do a recording is done in the file 'Scheduler.cs' in a procedure 'IsTimeToRecord' which I believe is triggered on a timer event every so often. In that procedure there is a switch statement that chooses one program path depending upon Recording Type (e.g. record once, record daily, record every time this channel etc.). Now what stands out to me in that switch statement is that the type for ETEC calls a procedure 'IsTimeToRecordEveryTimeOnEveryChannel' is to my eyes significantly different from all other recording types. If I had been writing it I probably would have based it similarly to the ETTC and simply checked through in a loop of every channel. The procedure being different to the rest might not catch an error condition the same as the other recording types and not handle an error as well as them hence the TVServer lock up being caused?</p><p></p><p>Ok thats it from me today as my tummy is rumbling and I need to go cook dinner!</p></blockquote><p></p>
[QUOTE="Berney, post: 1285887, member: 168121"] Hi everyone, I hope you all had a good weekend. Joecrow, yes it would seem there are differences between Germany and the Uk because there us no data in my provider column. CyberSimian, I absolutely agree with you that it would be useful to a) be able to recreate the problem easily so it can be a quality control test. And B) Narrow down where the problem is occurring as much as possible so that it can be put on a 'to fix' list when someone with the required skills comes along, making their job easier. I've done the following test over the weekend:- As suggested by CyberSimian I changed all the 'Record every time on every channel' (ETEC) instances to 'Record Every time on this channel ' (ETTC). There were 9 occurances. I've run the test over the weekend including up till now which is approximately 60 hours. The TVServer no longer locked up. The memory still filled up at around the same rate and up to the same amount full (approximately 1.6 gig). And the server has crashed 3 times, but it was able to restart each time due to windows service settings I have put in (i.e. restart the service in a crash). Where as previously the TVServer locked and was unable to easily restart it easily. So there has been some improvement but its not stopped the problem of a memory leak of some sort occurring. Now my next thought is what is the difference between CyberSimian's (CS) testing and my pre-test situation? If I understand CS correctly had the same number of ETEC recordings as I did (9). CS recordings happened successfully and no apparent memory leaks. Now here is the difference as I see it:- In my 9 recordings setup none of them occurred (because none of the 9 ETEC recordings were broadcast). So could it be that is the problem that yet to be recorded settings are left in memory and gradually build up till the memory is full ? This would seem to fit in with the way I record in general which I will explain. Generally I like to collect recordings not just for what I like to watch but to gather for when family and friends turn up and want to watch that they find interesting from my 'library' that I have built up. Often a friend will say 'hey I've just become interested in a series and I missed the first few episodes'. So I'll put in a scheduled recording for either ETEC or more likely ETTC. Over the years this has built up to many scheduled recordings that might happen say a couple of years in the future or not at all ever. The way I use Mediaportal means there are very many scheduled recordings that rarely get actually recorded, possibly using a lot of memory that some how builds up till it totally fills up. I've been trying to figure out the source code and from what I've deduced so far it would seem to me that the epg is grabbed from a broadcast stream in the file EpgDBUpdater.cs in the procedure 'ImportPrograms'. This is put into the sql database. Checking of is it time to actually do a recording is done in the file 'Scheduler.cs' in a procedure 'IsTimeToRecord' which I believe is triggered on a timer event every so often. In that procedure there is a switch statement that chooses one program path depending upon Recording Type (e.g. record once, record daily, record every time this channel etc.). Now what stands out to me in that switch statement is that the type for ETEC calls a procedure 'IsTimeToRecordEveryTimeOnEveryChannel' is to my eyes significantly different from all other recording types. If I had been writing it I probably would have based it similarly to the ETTC and simply checked through in a loop of every channel. The procedure being different to the rest might not catch an error condition the same as the other recording types and not handle an error as well as them hence the TVServer lock up being caused? Ok thats it from me today as my tummy is rumbling and I need to go cook dinner! [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Talk
Memory leak in TVService
Contact us
RSS
Top
Bottom