MediaPortal SVN-Snapshot:-07-25-2008 22-31h - Revision:19778.rar (5 Viewers)

[illStyle]

Hi,

although this SVN version is running stable so far in cannot confirm the speedup when turning TV on with that new option enabled. Compared to RC2 speed remains the same. I can now switch from SD to HD channels without MediaPortal crashing, though. This did not work in RC2.

Thanks for making MP better and better!!


Regards,
Simon

 

[romadd64]

In this SVN MiniEPG has become sluggish when there are a lot of channels in a group. In RC2 was lighting fast.
I think this was introduced with the fix of bug 1466 by Gibman (rev 19711), with the check of channel state. TVService does a query to the DB for every channel in the group.

I have more details :

If no other client is timeshifting, MiniEPG is sluggish; if another client is timeshifting, MiniEPG is fast. It seems that RC2 behavior it's reverted with the patch to bug 1466, that corrects sluggish EPG when another client is timeshifting.


romadd

 

[gibman]

Hi!

Yes, it is intentional.
Before we simply queried the server if it was timeshifting or recording - if "no" then assume all channels are available.

This just isnt good enough.

What if a card is disabled / not found then the channels associated with that card should become unavail.
We can revert back to how it was before with that simple algorithm described above, but then u also understand what can happen - false channel states.

Also, the reason why a timeshifting user has faster access to the mini EPG is simply because those cached channel states are now located on the user object on the server.

When u r not timeshifting, then the server does not know about you - (thus no user object) in other words it has to do a non-cached/slow channel states query on the fly.

/gibman

In this SVN MiniEPG has become sluggish when there are a lot of channels in a group. In RC2 was lighting fast.
I think this was introduced with the fix of bug 1466 by Gibman (rev 19711), with the check of channel state. TVService does a query to the DB for every channel in the group.

I have more details :

If no other client is timeshifting, MiniEPG is sluggish; if another client is timeshifting, MiniEPG is fast. It seems that RC2 behavior it's reverted with the patch to bug 1466, that corrects sluggish EPG when another client is timeshifting.


romadd

 

[diskeeper]

tvservice not available after standby/hibernate.

https://forum.team-mediaportal.com/...-nicht-tvservice-not-started-tvserver_log.zip

ps: the problem seems to be eliminated if i turn off setuptv/powerscheduler/reinitalize the service on wakeup.

 

[nschoot]

tvservice not available after standby/hibernate.

https://forum.team-mediaportal.com/...-nicht-tvservice-not-started-tvserver_log.zip

I can confirm this... I attached logs as well. This is what I did:

- Cleared logs (using tool)
- Started MP, Watched TV for a bit
- Pressed Stand-by (while watching TV) on remote
- Wait a bit
- Pressed Resume on remote
- MP started, error: "Unable to start time shiifting, Unknown error" -> The TV Guide info was there though.
- Shut down MP
- Went to TVServer config, tried to preview a channel there --> Failed
- Gathered logs

I installed the new TVService dll, but no difference. The original RC2 worked fine. I tried both with and without the preload graph options. No difference. I have PowerScheduled configured to reinit TVService after resume. (Without this the service won't work at all after resume)

Using: FireDTV, ATI Radeon HD 2600, MSSQL

 

[tourettes]

Also, the reason why a timeshifting user has faster access to the mini EPG is simply because those cached channel states are now located on the user object on the server.

Couldnt the server process cache all the channel states always? Using SQL to dothe work is just causing unnescessary delays. The channel state information doesnt need to persis between different server runs so I cannot see any reasons why it woulndt be possible.

 

[gibman]

Also, the reason why a timeshifting user has faster access to the mini EPG is simply because those cached channel states are now located on the user object on the server.

Couldnt the server process cache all the channel states always? Using SQL to dothe work is just causing unnescessary delays. The channel state information doesnt need to persis between different server runs so I cannot see any reasons why it woulndt be possible.

The channel states are not fetched from the database, nor do they exist there.

The main problem is that the channel state mechanism is done by iterating through the available cards on a given user.

If a user is not timeshifting, then the tvserver has no knowledge about the user- and since the channel states are based on an existing user then there isn't any cached data.

The reason why it is slow is not b/c of SQL - but simply b/c of the various iterations.

In order to have it cacheable, we need to introduce an "empty user" on each card.
This empty user's channelstates would then be used for miniepg on users that are not timeshifting.

/gibman

 

[Helios61]

DVB/S - Radio - Nearly perfect

Thank you for this SVN. Its the first version with nearly perfect DVB/S - Radio!

Regards
Helios

 

[pilotedge]

Hi,
I have some attached some logs regarding problems watching HD Channels. As someone mentioned earlier in the thread, I am also getting the "Waiting for VMR" in the log.... I can get audio only through the preview function in tv config, but this is mp2 audio rather than ac3....

 

[dyamant]

Hi..

can anyone explain what is "There is now added an option for TV-Server to preload graph for tuners."??
Benefictes?

Thanks!

Whre can i find this option ?