[solved] major issues with DVB-T channel change after upgrading to MP 1.34 (1 Viewer)

[CyberSimian]

DBV-T EIT EPG grabbing config as below, before and after the upgrade

Thank you for the screen shot of the "DVB EPG" panel, but two other panels also affect EPG grabbing. Please post screen shots of the "TV Epg grabber" and "Radio Epg grabber" panels (first page of each, if they consist of multiple pages).

At first sight, your settings are not a combination that I would use, but those settings may be appropriate for the Australian EPG.

In the UK, every MUX contains the EPG for the channels within that MUX, plus the EPG for all of the channels in all of the other MUXes. Do you know if the Australian MUXes are like this? This affects what constitutes the optimal choice of settings.

-- from CyberSimian in the UK

 

[CyberSimian]

I also found, that mediaportal instance was not quitting, as below, the MP GUI definitely quits, be evidently the process does not

I also experience this from time to time. Because it is sporadic (and evidently not encountered by everyone), identifying and fixing the problem is going to be difficult.

If this remnant of the MP client is still running when you next want to start the MP client, the START button on the remote control does nothing: the client does not start, and there is no pop-up error box. This annoyed me so much that I wrote an AutoHotKey script to trap the MCE START button, check for the MP remnant, terminate it if present, and then start the client. (The AutoHotKey script that I wrote for the Centarea HID already had this capability.) So these days I never see this problem, whichever remote control I am using (Microsoft MCE RC6 or Ortek VRC-1100).

-- from CyberSimian in the UK

 

[Hazza06]

I also experience this from time to time. Because it is sporadic (and evidently not encountered by everyone), identifying and fixing the problem is going to be difficult.

If this remnant of the MP client is still running when you next want to start the MP client, the START button on the remote control does nothing: the client does not start, and there is no pop-up error box. This annoyed me so much that I wrote an AutoHotKey script to trap the MCE START button, check for the MP remnant, terminate it if present, and then start the client. (The AutoHotKey script that I wrote for the Centarea HID already had this capability.) So these days I never see this problem, whichever remote control I am using (Microsoft MCE RC6 or Ortek VRC-1100).

-- from CyberSimian in the UK

TV and Radio EPG grabbing config as below, there are no digital radio channels as i had already deleted them all, in my earlier tshooting / isolation steps. Also the broadcaster here in Oz only broadcast one EIT in English only, i;ve never had to mess around with languages.


Yes Oz DBV-T FTA broadcasters TX their EIT for the channels within that MUX, is there a suggested better config i can try ?

Regarding the mediportal client process sometimes failing to quit, after quitting MP, i'll check Process Explorer how often the issue occurs before sending to S3 sleep, interestingly for me, on the single seat Win 7 x64 mediaportal, when there is a stuck prior mediportal client process still present, the new instance does actually start, but i wonder if this correlates to the issues im having, i'll have a dig through the logs, to see if it's detectable....

On the Windows 10 mediaportal client, yes when there is a stuck mediaportal process, the new process refuses to start....

 

[Hazza06]

think i got it, DVB EPG

about just selecting only one channel in the TV broadcaster MUX, to grab all channels in the EIT, rather than selecting all channels...i'll certainly give this a try, and understand how that optimized EPG grabbing.

but the documentation is quite vague, if you can have have timeshift EPG grabbing, and idle EPG grabbing enabled together....it seems to imply the way it's written one or the other....but not both....

There are many hours where our TV server, the single seat client not running, and is only a TV server running, essentially idle, and have also enabled idle EPG grabbing to make sure we have the most upto date EPG at any given point in time...


I've had in the past both timeshift EPG grabbing, and idle EPG grabbing enabled together for many years now, and never had issues, i understand is not optimal regarding the EIT having all channels EPG/EIT grabbing selected in one MUX, and i'll fix that now too, to see what improvement it can make....

Again, many thanks for showing an interest, and making some suggestion's, is very much appreciated.

 

[Pablik]

I don't think the Suspend/Resume is responsible for the slow process.
Check these log lines:

[2024-08-02 20:16:46,516] [Log    ] [7        ] [INFO ] - GetAvailableCardsForChannel: found 2 card(s) for channel
[2024-08-02 20:16:46,516] [Log    ] [7        ] [DEBUG] - GetAvailableCardsForChannel took 232 msec

The diff is 0ms as it should be(right after service startup). But later we can see rising difference:

[2024-08-02 21:05:07,659] [Log    ] [10       ] [INFO ] - GetAvailableCardsForChannel: found 2 card(s) for channel
[2024-08-02 21:05:07,702] [Log    ] [10       ] [DEBUG] - GetAvailableCardsForChannel took 415 msec

Also check the signal logging:

[2024-08-02 20:16:49,668] [Log    ] [7        ] [DEBUG] - card: Tuner locked: True
[2024-08-02 20:16:49,668] [Log    ] [7        ] [INFO ] - **************************************************
[2024-08-02 20:16:49,683] [Log    ] [7        ] [INFO ] - ***** SIGNAL LEVEL: 0, SIGNAL QUALITY: 100 *****
[2024-08-02 20:16:49,699] [Log    ] [7        ] [INFO ] - **************************************************

All timestamps should be within 1 ms. There is no code execution. Just logging.

The MediaPortal client is also affected:

[2024-08-02 21:22:46,660] [Log    ] [MPMain   ] [INFO ] - overlay: video WxH  : 1920x1080
[2024-08-02 21:22:46,675] [Log    ] [MPMain   ] [INFO ] - overlay: video AR   : 1920:1080
[2024-08-02 21:22:46,684] [Log    ] [MPMain   ] [INFO ] - overlay: screen WxH : 1x1
[2024-08-02 21:22:46,694] [Log    ] [MPMain   ] [INFO ] - overlay: AR type    : Normal
[2024-08-02 21:22:46,704] [Log    ] [MPMain   ] [INFO ] - overlay: PixelRatio : 1
[2024-08-02 21:22:46,713] [Log    ] [MPMain   ] [INFO ] - overlay: src        : (0,0)-(1920,1080)
[2024-08-02 21:22:46,723] [Log    ] [MPMain   ] [INFO ] - overlay: dst        : (0,0)-(1,1)

It should be within 1ms too. Like from my logging:

[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: video WxH  : 0x0
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: video AR   : 0:0
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: screen WxH : 1920x1200
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: AR type    : Normal
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: PixelRatio : 1
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: src        : (0,0)-(0,0)
[2024-08-02 20:31:37,186] [Log    ] [MPMain   ] [INFO ] - overlay: dst        : (0,-2147483648)-(1920,0)

 

[CyberSimian]

TV and Radio EPG grabbing config as below

Thank you for posting the additional screen shots. Those settings would certainly not be optimal for the UK, but Australia may be different. I have included screen shots of the settings that I use:



I grab once per day using the idle grabber. I use PowerScheduler (in "Advanced" mode) to wake the HTPC to grab the EPG at 06:00 hours. In the UK the EPG is updated at midnight with 24-hours of programme info for the day that is 7/8 days in the future, so grabbing somewhere between 01:00 - 06:00 hours is a good choice.

I specify a long grab duration of 60 minutes. TV Server can detect when it has seen the entire EPG, and it stops grabbing. So there is no disadvantage in specifying a grab duration longer than you think is necessary. In the UK, it takes around 10-15 minutes to grab the entire EPG, followed by 15-20 minutes to update the EPG database on my relatively slow Western Digital Green drive.

I select only one TV channel ("BBC1") and no radio channels. With the settings shown, TV Server grabs and stores the EPG for all channels in all MUXes.

In principle, in the UK all MUXes are equal with regard to the EPG, but some MUXes are more equal than others. In particular, the BBC MUX treats all channels equally, and does not favour its own channels. Experience with other MUXes suggests that those MUXes favour their own channels (whilst still broadcasting a complete EPG containing everything). So you might need to experiment to determine if one of the Australian MUXes is more neutral than the others with regard to the EPG.

-- from CyberSimian in the UK

 

[CyberSimian]

but the documentation is quite vague if you have have timeshift EPG grabbing, and idle grabbing enabled together....it seems to imply the way it's written one or the other....but not both....

Sadly, there is a functional quirk in the way that the idle and timeshift EPG grabbers work.

Using the idle grabber, TV Server will tune in turn to each selected channel, and grab the entire EPG from that channel (assuming that the grab duration is long enough). This is why it is a bad idea to select more than one channel when using the idle grabber with MUXes that contain the EPG for all channels in all MUXes. TV Server will repeatedly grab the same EPG, when it actually needs to grab the EPG only once.

The circumstance when you would need to select more than one channel when using the idle grabber is for those countries where each MUX contains the EPG only for its own channels, and does not contain the EPG for channels in other MUXes (I think that France is like this). In this case you would select one channel in each MUX. I also think that this is the only case where the setting Use all available tuners provides any benefit.

Using the timeshift grabber, TV Server will grab the EPG only when tuned to a channel that has been selected for grabbing. If you have selected only one channel (because you are using the idle grabber), timeshift grabbing will occur only when you watch or record that specific channel, and not when you watch or record other channels.

To get timeshift grabbing to work regardless of which channel you are watching or recording, you would need to select all channels for grabbing, which is in direct contradiction to the optimal choice for idle grabbing.

EPG grabbing could be improved, but it is a complex area that would take a lot of work to understand and get right (so unlikely to change, I think).

-- from CyberSimian in the UK

 

[Hazza06]

understood, and thanks for sharing the UK best practice for optimized EPG grabbing suggestion, this is really useful, i've increased idle EPG grabbing timeout to to 15 minutes, as my PC OS runs on SATA3 SSD, recordings on a separate dedicated 100GB SATA3 SSD, and RAM disk for live TV timeshifting, it's lightening quick, so i'll see how it goes. I'll closely monitor it in next few days to see if it needs increasing.

I can already see how un-optimized my EPG grabbing configs were, and how much more efficient you suggestion is..thanks again for sharing.

As Oz also broadcasts all channel EIT in same provider MUX, i've also adopted your optimized suggestion, as below. If all goes well, and i'm optimistic, time to disconnect that darn FetchTV STB, so slow and cruddy....MP so much better ;-)

I too like you, use powerschedular, to daily wake the PC to refresh the EPG, i'll review that as well, i'm fairly sure it's ok...

The only other thing i'll likely need to look into further, is the mediaportal occasionally not quitting, you mentioned a AutoHotKey script, would by any chance you also be able to share some details around that ? I also have the Microsoft MCE RC6 remote and keyboard...and IR receiver

 

[Hazza06]

interesting, did some more testing, after S3 resume, and had some channel change issues again, but i am very confident i have now found the root cause, Microsoft security essentials (MSE) process was consuming copious amounts of CPU, whilst i was having channel change issues, i've for now disabled MSE, and instantly resolved channel change issues...

Darn MS crud, i haven't updated MSE itself for a long time, but it is set to update signatures every day, somethings obviously gone amiss with MSE on Win 7....i'll look into this MSE issue further... oh the joys of running an old unsupported OS ;-) i'll likely leave it disabled, as i rarely use a browser on it, and only really ever use MP....it's a dedicated HTPC appliance. And it sits in a fort knox DMZ as well.

I can't really upgrade to Win 10, no official win 10 ATI GFX drivers, win 7 drivers may potentially work in Win 10, but what a pain.....

I think we should now close this as solved ;-) looks like it wasn't a MP issue at all, but darn MSE issue...

 

[CyberSimian]

The only other thing i'll likely need to look into further, is the mediaportal occasionally not quitting, you mentioned a AutoHotKey script, would by any chance you also be able to share some details around that ?

I attached the "MpStart" support pack to this post. Download it and give it a try.

i haven't updated MSE itself for a long time, but it is set to update signatures every day, somethings obviously gone amiss with MSE on Win 7

I too still use Windows 7 (the 64-bit version), but I disabled Windows Update when Microsoft discontinued updates for it. I think that I might have disabled the antivirus scanning too (I would need to check). The only time that my HTPC accesses the internet is when I am installing a new release of MP; my HTPC is not used for internet browsing, or email, or general computer work, and it sits behind an internet router. So I think that the lack of active antivirus software is not a big risk. (I use Microsoft Security on the Windows 10 laptop that I am posting from.)

-- from CyberSimian in the UK