TV Guide very slow vertical scrolling since RC3 (1 Viewer)

[disaster123]

mhm than i have a totally different problem:
1. only 10 recordings in DB
2. using MSSQL
but vert scolling extemely slow and sluggish - no MSSQL load on the server.

 

[rtv]

mhm than i have a totally different problem:
1. only 10 recordings in DB
2. using MSSQL
but vert scolling extemely slow and sluggish - no MSSQL load on the server.

Not recordings - schedules!

1. Skin?
2. Some playback active?
3. Which GPU + Memory?
4. packLogoGfx enabled?

 

[disaster123]

Not recordings - schedules!

1. Skin?
2. Some playback active?
3. Which GPU + Memory?
4. packLogoGfx enabled?

sorry i meant schedules - used wrong word.

1. StreamedMP - with 10 guides in parallel
2. No - sometimes makes no difference
3. Client 1: ATI 4350 512MB and on Client 2 ATI 3200 onboard with 128MB Sideboard + 512MB shared
4. nothing set so default MP Setting

 

[Mr Hipp]

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

I don't think this will solve the problem. You still need to poll the db. The proper way is to implement events. The above kind of solution is the one that creates the mess we are into already.

 

[tourettes]

I don't think this will solve the problem. You still need to poll the db. The proper way is to implement events. The above kind of solution is the one that creates the mess we are into already.

Even events wouldn't be required if EPG table would be extended with one additional item to hold notify / recording info and that would be updated in two cases:

1) during EPG grabbing (every new entry checked if it is to be recorded or notified)
2) during new schedule creation (every EPG entry is checked if it is to be recorded or notified)


Any combination of following:

• 0x0 none
• 0x1 notify
• 0x2 record
• 0x4 record series

That way the EPG grabbing time would increase (not a big deal as it is done only once, not constantly like EPG refreshes are doing it). Also inserting a new schedule would get a little bit slower. But as a result there would a EPG view that doesn't get any slower even when user has 1000 schedules in the DB.

Any volunteers to implement such?

update: after reading gibman's proposal it is pretty much the same (notify wouldn't work ). As we normally need to query the DB for EPG content it will be not adding any extra polling need as Mr Hipp was saying.

 

[Mr Hipp]

Sorry I think I have missunderstod gibmans proposal. It's good.

Mr Hipp

 

[disaster123]

Is it def. clear that this is the problem? Is there an easy way to remove the red dot code from source and test if it runs fine than?

 

[rtv]

Is it def. clear that this is the problem? Is there an easy way to remove the red dot code from source and test if it runs fine than?

There has already been a thread like this before where I uploaded binaries which removed the nested loops. Users where really happy with it and started to nag for "updates" to these binaries for newer releases

 

[disaster123]

rtv
could you post a patchfile here? I would like to test / try it with the actual SVN code. The patch can be old no need for an up2date version. Thanks!

 

[rtv]

@rtv
could you post a patchfile here? I would like to test / try it with the actual SVN code. The patch can be old no need for an up2date version. Thanks!

Sorry - I am quite busy this week but I guess someone will use the search button for you or provide the patch. However it might still be possible that you suffer from an additional problem. I've read some threads in gigabyte's forum that their sideband memory boards are painfully slow as soon as the memory demands of apps are higher than the amount of dedicated memory available.