IPTV not working (1 Viewer)

[mm1352000]

Andrusha777

I have noticed, that in TV Server channels config i cand add several tuning details in each channel. So if i scans a one IPTV channel several times with different SID, but with same IP, woul TV server try to show it channel with several tuningdetails when SID changes?

It might at the moment because I think it compares channel names to see if the tuning detail from a scan should be added to an existing channel. Starting with MediaPortal 1.2.0b it will only do that if the ONID, TSID and SID are the same.

What you could do to save yourself time is to scan in the channels that have been lost, combine them with the old channels using TV Server configuration TV Channels->TV Combinations (so you would have 2 tuning details per channel), then delete the tuning detail that doesn't work any more.

 

[paalkr]

Re: AW: Re: IPTV not working

Hi paalkr,

the broken ts file from your first post looks as if the rtp header weren't removed properly. The filter checks every single packet if the rtp headers are correct. If this check fails for 5 sequent packets, it switches back to raw udp. Perhaps this happens here.

The logs doesn't contain the relevant information to be sure. Please replace your current MPIPTVSource.ax with the debug version from this post. Make a backup first!! Then start TV Server config and start timeshifting in manual control of one of the not working sd channels. Let the timeshift run for about 5 sec and stop it. The debug version creates a log file, please post it here. Don't forget to replace the debug version with your backuped one.

Not all SD channels seems to work OK either.
New log file attached. Hope this helps.

Does this mean that working channels always work and channels not working nerver work? Or is it sometimes working and sometimes not?

Also had a very short look at your dumps. The header in the files look good to me. So we have to wait for the log file.

Stepko

Hi!

First. Yes, the same SD channels fails all the time, and the ones that work works OK all the time.

I'm really thankful that you look into this issue. I have now done some recordings with the debug filter, and can report of 5 different scenarios. Log files and sample ts stream is provided for all 5 examples. I have attached links because of the size of the logs and ts streams.

1. HD channel with corrupted header
2. SD channel with corrupted header
3. Stuttering sound (graph screenshot included in link)
4. Failed to create / load graph
5. SD channel - everything OK

I really hope that the issues can be ironed out, and I will gladly contribute with testing.

Regards,
PK

 

[Andrusha777]

mm1352000, about last year i'm doing exactly the same, you are suggesting to me - i'm scanning lost channels and change tuning details in them manually that's not the way i'm looking for :-(
So i want to do some automation - write soft using ODBC and VBA, which would scans all channels from iptv playlist in batch mode, create new m3U playlist to update, then replace ALL old tuningdetails with new ones. This should run by task scheduler, but i don't know how to scan channels with tv server from command line?

 

[Stepko]

AW: Re: IPTV not working

paalkr
I think we should first focus on your issues 1 and 2.
The other two may be related or may be codec issues. Is the same codec used for all channels?

Back to 1 and 2: The logs of these two attemts are very similar. So in fact this is only one issue. We need some more testing (can not say how much until we find it ). Your log looks very good - in the first 600ms. Then the first packet loss happens, which is not really a big deal. But from that point on every 28th packet get lost. Well, I can say that there is a packet lost, but the log is missing the info how many packets are lost. It's strange that packets get lost after exactly every 28 packets.
To get even more log output you will find a different debug version of the filter. Please get some log with that version. 5 seconds are enough, this version will output a lot more!

And to anybody else: Do NOT use this version!


Stepko

 

[paalkr]

Re: AW: Re: IPTV not working

@paalkr
I think we should first focus on your issues 1 and 2.
The other two may be related or may be codec issues. Is the same codec used for all channels?

Back to 1 and 2: The logs of these two attemts are very similar. So in fact this is only one issue. We need some more testing (can not say how much until we find it ). Your log looks very good - in the first 600ms. Then the first packet loss happens, which is not really a big deal. But from that point on every 28th packet get lost. Well, I can say that there is a packet lost, but the log is missing the info how many packets are lost. It's strange that packets get lost after exactly every 28 packets.
To get even more log output you will find a different debug version of the filter. Please get some log with that version. 5 seconds are enough, this version will output a lot more!

And to anybody else: Do NOT use this version!


Stepko

Thanks! New log attached, but after about 5 seconds TV server config (manual control) gives an error about no audio / video stream found. Anyway, the logs seems OK. When I switch back to the non debug filter, that error message goes away so I guess that the error is somehow intended (or expected) by you.

I agree with you, 1 and 2 is probably the same and only issue that are relevant for the IPTV filter. I even suspect that the stuttering sound on some channels can be due to lost packets, and then somehow connected to 1 and 2.

BTW. The log that is OK (5), how does that differ from the corrupted streams?

Regards,
PK

 

[Stepko]

AW: Re: AW: Re: IPTV not working

Thanks! New log attached, but after about 5 seconds TV server config (manual control) gives an error about no audio / video stream found.

No, that was not intended. In fact that was a bug
But the first second was OK, so I could use the log.

There were 2 bugs in the last debug version. One causing the no audio/video message. When a packet got lost at a special time the filter stopped working.

The other caused a lot of lost packet lines in the log even though the packets were received. This bug didn't have any other side effects.


I don't know if these issues existed in the first debug version, too. That version was pretty old and I changed a lot in the packet handling and lost packet handling code. And exaclty there I found the bugs.

So I think it's time to give it another try. Paalkr, you know what you have to do

BTW. The log that is OK (5), how does that differ from the corrupted streams?

Not so many packet losts

Stepko

 

[paalkr]

Stepko

Thanks for the feedback, and that you bother helping out with this. I really appreciate that. New log file attached (no error messages from manual control now). I hope that the new log files gives you some more hints on whats wrong.

If you need some raw TS dumps grabbed with the filter, just let me know.

Regards,
PK

 

[paalkr]

Re: AW: Re: IPTV not working

Hi!

First. Yes, the same SD channels fails all the time, and the ones that work works OK all the time.

I'm really thankful that you look into this issue. I have now done some recordings with the debug filter, and can report of 5 different scenarios. Log files and sample ts stream is provided for all 5 examples. I have attached links because of the size of the logs and ts streams.

1. HD channel with corrupted header
2. SD channel with corrupted header
3. Stuttering sound (graph screenshot included in link)
4. Failed to create / load graph
5. SD channel - everything OK

I really hope that the issues can be ironed out, and I will gladly contribute with testing.

Regards,
PK

Hi Stepko!

I did a timeshift with your latest debug filter on Disney Playhouse (issue 3) and could not find any lost packages, so I guess that there are some other strange thing happening with that channel. My two cents is that the problem is related to some codec issues, as you also suggested. I only have trouble with that particular channel though (at least I think so). Do you have any suggestions on how I could hunt down the problem? Luckily Disney Playhouse happens to be a FTA channel, so I can tune it with VLC, and there I see (or rather hear ) no stuttering.

PS! Waiting with great anticipation the outcome of your analyzes of the latest log file. I'm hoping to see a miraculous new working IPTV filter

Regards,
PK

 

[Stepko]

AW: Re: IPTV not working

I hope that the new log files gives you some more hints on whats wrong.

Yes, very interesing log. But I don't think you want to know...

The log reports very heavy packet lost! A lot of packets get lost. In the rtp-header there is a sequence number for each packet. Of course this number should increase by one on every packet. Well, from your log, just as an example:
51259, 51260,51265,51267,51268,52035,52038,52040
There is a hole of almost 800 packets

These packet losts doesn't happen all the time. For some seconds everything is fine and then there is some time with massive packet losts.

The filter puts some packets in a buffer and sends that buffer to the next filter in the graph. When the packets get lost none of the buffers sent to the next filter contains continuous data. Thats why the picture is like it is.

I don't know how fast your system is. Don't know how good your AMD cpu is, but I think it is little faster than mine. Some of the drops might be related to the log output, which consumes a lot of the cpu power.

I will attach two versions of the same filter: debug version will only output the sequence numbers of the packages as soon as they arrive. The other version doesn't output anything. If you have anything running in background that uses the cpu a lot you should stop that. If you have a firewall running, you should stop that, too. (You won't belive how slow some firewalls are..)

With a little bit of luck there might so improovements. But don't expect miracles. I think it's just your connection... :sorry: but why do some channels work?!?!?

Please post the log of this debug version.

Stepko

Edit: Ha, just got an idea in the second I pressed the send button. You will find another version of the filter: MPIPTVSource_doesNothing_debug and it does what the name suggest: Nothing
It just receives the stream, get the sequence numbers, write them in the log and throws the data away. The aim is to disable the filter as much as possible and see if the packet lost still happens. This version will not work but I hope the TV server let it run for a few seconds. I didn't test that version and had to comment out almost everything. If I did something wrong (e.g. missed a bracked) it will just crash. But you should give it a try and post the logs.

 

[paalkr]

WOW!!!!

This is great Stepko! The DebugDoNothing filter actually print out the packets in the right sequence, but the CPU hits the roof. The DebugNoLogging filter seems to work great! Timeshift and recording of one HD channel results in a CPU usage of approx 35%. Timeshifting and recording two HD channels at the same time brings the CPU up to approx 60%. The DebugProcess filter also brings the CPU to 100%, but there seems to be no packet loss.

I guess that the IPTV filter is far more demanding for the CPU than a regular DVB-x grabber card? My setup is BTW wired Cat5e Gbit to all rooms in the house, with two Gbit Dlink switches (on at each floor) for hooking up the drop cables. The Fiber connection is 100/25 Mbit, where TV uses QoS in the router provided from my ISP.

For some reason the playback of HD channels in MePo stutters slightly (on some occasions) even when the CPU is about 50%. Maybe Microsoft DTV is not the best codec, could ffdshow dxva turn out to be better. Or could there maybe still be some packet loss in the IPTV filter? The last is quit hard to find out, because the filters with logging consumes 100% CPU and therefore cannot be used to evaluate picture quality.

Anyway, lack of CPU power on the TV server seems to be the culprit. Maybe I need to set up one central TV server with some quad core CPU or something.

The good thing - the latest filter seems to work, and if there are any chances of optimizing the code, the low end TV servers would benefit from that.

Logs attached. I have not studied the packet sequences in detail, so there could still be some glitches. I guess that you could analyze that pretty easy with some text processing code or some scripting (unfortunately I don't have that kind of knowledge).



Edit: I'm adding a complete MePo debug log, if that could be of any help determining the reason for the stuttering playback on the HD channels. CPU is not higher than approx 40-60% (using you latest no logging filter).

Regards,
PK