If I remember correctly the DVB specs are saying that PMT should be injected to the stream in 0.2 second basis. Of course some broadcasters aren't playing nicely with this and even 1 per 1 second times can be happening. This is too much (actually even 200ms delay on a fast zapping is too much, as it is approx 25% increase on good zapping times).
[Rejected] Patch to fix "No PMT" or "PMT Timout" errors (2 Viewers)
- Thread starter DJBlu
- Start date
If I remember correctly the DVB specs are saying that PMT should be injected to the stream in 0.2 second basis. Of course some broadcasters aren't playing nicely with this and even 1 per 1 second times can be happening. This is too much (actually even 200ms delay on a fast zapping is too much, as it is approx 25% increase on good zapping times).
Greece
Sounds plausible (I cannot see why it wouldn't be possible, as we are just dealing with some streamed data).
Edit:
Unless TsWriter / TVE3 is trying to use the cached information to pick up the audio / video / subtitle PIDs before seeing any PMT in the strteam itself. But maybe that could be overcome as well with polling the new "possible" PMT and trying to "catch" the audio / video / subtitle PIDs in the sametime.
That seems to me a perfect solution.
Only thing that would be needed: If the PMT ID received is different from what is stored in the database you would have to somehow cancel the PMT grabber and grab the new PMT.
Hi,
I would like to give a help with this problem (I've got it...). I've tried several solution but the problem seems to be in the DirectShow Filter: probably, they became busy or full of data and they stop.
A temporary solution can be found in this patch:
As you can see, before tuning a channel (satellite channel) I pause the _graphbuilder and I start it again before running the graph: this patch seems to work but moving between channel is slower (approx 6-7 second) and before showing a channel, the last frame of previous channel is showed.
Well, give me your opinion about my solution and if it can be improved
I would like to give a help with this problem (I've got it...). I've tried several solution but the problem seems to be in the DirectShow Filter: probably, they became busy or full of data and they stop.
A temporary solution can be found in this patch:
Code:
Index: TvCardDVBS.cs
===================================================================
--- TvCardDVBS.cs (revision 23209)
+++ TvCardDVBS.cs (working copy)
@@ -190,7 +190,20 @@
public ITvSubChannel Tune(int subChannelId, IChannel channel)
{
DVBSChannel dvbsChannel = channel as DVBSChannel;
-
+
+ ///////////////////////////////////////////////////////////////////////
+ if (_graphBuilder != null)
+ {
+ FilterState state;
+ ((IMediaControl)_graphBuilder).GetState(10, out state);
+ if (state == FilterState.Running)
+ {
+ IEnumFilters Filtri;
+ _graphBuilder.EnumFilters(Filtri);
+ ((IMediaControl)_graphBuilder).Pause();
+ }
+ }
+ ///////////////////////////////////////////////////////////////////////
if (dvbsChannel == null)
{
Log.Log.WriteFile("Channel is not a DVBS channel!!! {0}", channel.GetType().ToString());
@@ -284,6 +297,18 @@
}
try
{
+ ///////////////////////////////////////////////////////////////////////
+ if (_graphBuilder != null)
+ {
+ FilterState state;
+ ((IMediaControl)_graphBuilder).GetState(10, out state);
+ if (state == FilterState.Paused)
+ {
+ ((IMediaControl)_graphBuilder).Run();
+ }
+ }
+ ///////////////////////////////////////////////////////////////////////
+
RunGraph(ch.SubChannelId);
} catch (TvExceptionNoSignal)
{Well, give me your opinion about my solution and if it can be improved
Update: now it works! It was correct from first time: the problem I've got was due to an EIT filter I'm implementing. Replacing modified tswriter.ax with original ones (Tv server 1.1.0 alpha), everything works fine.
The correct patch is showed below (the first has an incorrect and not working declaration)
I attach both patch file (showed above) and compiled TvLibrary.dll (so you can try by yourself...)
The correct patch is showed below (the first has an incorrect and not working declaration)
Code:
Index: Implementations/DVB/Graphs/DVBS/TvCardDVBS.cs
===================================================================
--- Implementations/DVB/Graphs/DVBS/TvCardDVBS.cs (revision 23209)
+++ Implementations/DVB/Graphs/DVBS/TvCardDVBS.cs (working copy)
@@ -190,7 +190,17 @@
public ITvSubChannel Tune(int subChannelId, IChannel channel)
{
DVBSChannel dvbsChannel = channel as DVBSChannel;
-
+ ///////////////////////////////////////////////////////////////////////
+ if (_graphBuilder != null)
+ {
+ FilterState state;
+ ((IMediaControl)_graphBuilder).GetState(10, out state);
+ if (state == FilterState.Running)
+ {
+ ((IMediaControl)_graphBuilder).Pause();
+ }
+ }
+ ///////////////////////////////////////////////////////////////////////
if (dvbsChannel == null)
{
Log.Log.WriteFile("Channel is not a DVBS channel!!! {0}", channel.GetType().ToString());
@@ -284,6 +294,17 @@
}
try
{
+ ///////////////////////////////////////////////////////////////////////
+ if (_graphBuilder != null)
+ {
+ FilterState state;
+ ((IMediaControl)_graphBuilder).GetState(10, out state);
+ if (state == FilterState.Paused)
+ {
+ ((IMediaControl)_graphBuilder).Run();
+ }
+ }
+ ///////////////////////////////////////////////////////////////////////
RunGraph(ch.SubChannelId);
} catch (TvExceptionNoSignal)
{I attach both patch file (showed above) and compiled TvLibrary.dll (so you can try by yourself...)
Unfortunately such huge zapping delays are a big no go. We cannot add any patches that will make the user experience worse.
In my opinion that is only a hack to overcome some bad hardware (or mainly driver bugs). Much better way would be to issue a re-tune if buggy drivers / CAM are failing during the tuning process.
In the "update version" there's no more delay: delay was due to my incorrect filter (not yet completely developed).
With or without my patch, time required for zapping is the same.
That might be only true for the specific HW / drivers you have been testing. So it would be still better to handle the error cases only (when tuning fails). Who knows if such quick pause & resume triggers another driver side bug on some other HW?