- December 6, 2007
- 432
- 14
- Home Country
-
Netherlands
4therecord has superb scrolling speed.
TV Guide very slow vertical scrolling since RC3 (1 Viewer)
- Thread starter robby3
- Start date
This clearly shows the downside of people making profit of open source. The original project doesn't "get back" from these...
Still - the TV Guide can easily be changed to quick again. Just some fix from gibman to display upcoming schedules correctly has to be removed. If your DBMS is slow and a smooth guide has higher priority than a correct "red dot" just some code parts need to be commented out.
- May 14, 2008
- 3,558
- 434
- Home Country
-
Germany
I'm not shure if this is really DB related. I've looked onto my tv-server and the sql thread only rises up to 7-9% CPU. Also at least for me the scolling is fast until i reach the end of the page and new channels have to come up. Same but not as slow as verticel is the horizontal scrolling when i'm at the right end of screen. I'm using 10 channels in tvguide (StreamedMP).
For someone who want's to fix the slow EPG scrolling issue (by providing a patch). EPG / recording dot should handling should be changed in the following way. Currently the recording dot visibility and type) is analyzed constantly, causing a huge stress on CPU (and even most likely for MySQL as it's cache implementation seems to be many times worser than MS SQL's). Instead the recording dot state information should be persistent in DB and updated only when the recording schedules are changed or new programs are added to DB (EPG update).
And someone could ad this slow scrolling to Mantis for future releases (I wont as I don't have enough channels to see this behavior
).
And someone could ad this slow scrolling to Mantis for future releases (I wont as I don't have enough channels to see this behavior
).
callback events from server to client is not supported (remoting) afaik.
looking in tvguidebase.cs @ l:1976 and l:3077
it does some nested loops to find out if tvguide entry (program ) is recording or not.
foreach (Program program in programs)
.... foreach (Schedule record in _recordingList)
The best and most efficient way would be to have a "IsRecording" field on the "program" database table.
making this possible: program.IsRecording
it would increase speed tremendously.
It would then be the job of the scheduler code in tve3 to set this value in the database correctly.
meaning true when starting a rec. and false when stopping it.
was looking at the current datamodel.
I often miss the relation between a program-schedule-recording.
example.
table "schedule" should have a foreign key pointing to the program table ..ex "program_id"
table "recording" should have a foreign key pointing to the schedule table ..ex "schedule_id"
With a record object, we can always get the referenced schedule.
and with a schedule object we can always get the referenced program, if any.
As I see it, a lot of code can be simplified from this.
ofcourse we have to maintain integrity.
deleting a schedule but keeping its recordings ?
What will happen to the recordings that are currently associated with the deleted schedule.
etc etc.
/gibman
looking in tvguidebase.cs @ l:1976 and l:3077
it does some nested loops to find out if tvguide entry (program ) is recording or not.
foreach (Program program in programs)
.... foreach (Schedule record in _recordingList)
The best and most efficient way would be to have a "IsRecording" field on the "program" database table.
making this possible: program.IsRecording
it would increase speed tremendously.
It would then be the job of the scheduler code in tve3 to set this value in the database correctly.
meaning true when starting a rec. and false when stopping it.
was looking at the current datamodel.
I often miss the relation between a program-schedule-recording.
example.
table "schedule" should have a foreign key pointing to the program table ..ex "program_id"
table "recording" should have a foreign key pointing to the schedule table ..ex "schedule_id"
With a record object, we can always get the referenced schedule.
and with a schedule object we can always get the referenced program, if any.
As I see it, a lot of code can be simplified from this.
ofcourse we have to maintain integrity.
deleting a schedule but keeping its recordings ?
What will happen to the recordings that are currently associated with the deleted schedule.
etc etc.
/gibman
Added a work-in-progress patch.
It's based on the "program" table having a Isrecording bit, the sames goes for the "recording" table.
u need to add these 2 fields by urself.
No time for SQL script here
Even though this is now optimized in the tvplugin code (tvguidebase.cs) -- vertical scrolling is still slow'ish, horizontal scrolling is fast.
In other words, couldnt see any difference.
sql 2005 sever here.
/gibman
It's based on the "program" table having a Isrecording bit, the sames goes for the "recording" table.
u need to add these 2 fields by urself.
No time for SQL script here
Even though this is now optimized in the tvplugin code (tvguidebase.cs) -- vertical scrolling is still slow'ish, horizontal scrolling is fast.
In other words, couldnt see any difference.
sql 2005 sever here.
/gibman
- May 14, 2008
- 3,558
- 434
- Home Country
-
Germany
does this mean, that the problem is not caused by the recording dot?
You need a bunch of schedules in your DB and even then you'll notice the issue mainly with with MySQL (as SQL Server will have the complete DB in RAM at that point).