IPTV not working (5 Viewers)

[Stepko]

AW: Re: IPTV not working

The DebugDoNothing filter actually print out the packets in the right sequence, but the CPU hits the roof.

The logs confirms that. There are only very few packets that got lost. But there was a total drop out for 1,5 seconds. Nothing in the logs for 1,5 seconds. That CPU hit the roof is OK.

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%.

No, no, no. This is far, FAR too much. There is something wrong. My dev machine is a 7 year old AMD athlon 64 (single core, AMDs first 64 bit cpu) with 2,4 gHz. Timeshifting a SD channel takes about 5-7% cpu power. When I record a SD channel with the filter from yesterday in GraphStudio the cpu is at 0-2%.

In general: The IPTV filter doesn't need very much cpu power. Depending on your provider it handles about 300kb - 1,5 MB of data per second, which is nothing for current PCs.
What really needs a lot of cpu power is the logging in the debug versions of the filter.

As written above there is a 1,5 sec gap in one of your logs. Are you sure that there was no background process running, which could have caused that?

The next step is to find the cause for the high cpu usage. It must be either the filter or the TV Server. I would suggest you test the filter (the release verion without any logging from yesterday) in GraphStudio:

- Download GraphStudio here
- Start it and select "Graph"->"Insert Filter..."
- Select "Mediaportal IPTV Source" and click on "Insert"
- As URL use one of the channels that do not work (rtp://233.x.x.x:yyyy)
- Close the insert dialog
- Right click on the out pin of the filter to insert a dump filter
- Let the output write to a .ts file (dump.ts)
- Start the Graph with the play button
- Let the graph run for 30 seconds and keep an eye on the cpu usage of graphstudio.exe
- When you have stopped the record try to play the dump.ts in vlc
- If it plays in vlc without problems try to play it in MP

Stepko

 

[paalkr]

Hi Stepko!

I did what you suggested and the CPU consumption for graphstudio.exe is about 2-5% when dumping a HD channel, and about 1-2% when dumping a SD channel. If I then timeshift the same HD channel with manual control in TV server the CPU consumption increases to approx 15-25% for TvService.exe.

BTW - I'm performing the tests on my desktop computer now, with a AMD Athlon 64 X2 4600+ 2,4 GHz CPU, and a ATI Radeon HD 43xx with latest catalyst driver. The OS is Win7 x64 ultimate.

Playback of the HD recording done with TV server stutters big time in VLC, while the CPU cruses at 55% during playback. This tells me that there might be some errors in the ts stream, hence some packets could be lost. Playback with MPC-HC is a lot smoother, but especially the sound stutters from time to time. The CPU load is approx 35%.

I cannot playback anything that is just dumped with graphstudio because all the HD channels (and most SD channels) are encrypted with Conax. As far as I know there is no hardware CAMs that work with the software IPTV card in MePo, so I have to stick to the MDAPI solution (shhh..., don't tell anyone ). I have some FTA SD channels (no FTA HD), but non SD channels are troublesome (except Disney Playhouse that is in fact one of the FTA channels ).

I tried to timeshift one of the FTA SD channels with CAM support disabled on the IPTV card, and then timeshif an encrypted SD channel with CAM support enabled. The difference in CPU load was only 2-3% (an increase from 3-5% to 5-7% CPU load). And as I said timeshifting an encrypted HD channel consumes approx 15-25% CPU on the TvService.exe (same operation with graphstudio consumed approx 2-3% CPU).

Could the problem be related to how the IPTV filter communicates with the CAM implementation in the software IPTV card?

At least it doesn't look like the filter is the problem, but rather something in the TV server pipeline. All my log reports has contained the MDAPIfilter log as well, could it be something interesting in them?

I really hope that we are able to track down the error, I'm feeling that we have circled in the possibilities. But on the other hand, if it's not the IPTV filter it could be harder to get support (especially if it turns out to be MDAPxxx related).

Regards,
PK

 

[mm1352000]

Just to confirm, this is only timeshift (not viewing) that you're talking about when you say:

If I then timeshift the same HD channel with manual control in TV server the CPU consumption increases to approx 15-25% for TvService.exe.

Hmmm. Have you tried Miroslav's stuttering patch? I'm just wondering whether the extra HDD IOs that Miroslav's patch fixes also affect the TV Service CPU usage. They shouldn't unless your HDD is working in PIO mode rather than UDMA mode...

p.s. No more discussion of MD*** here please. It is enough to say "encrypted" or "FTA".

 

[paalkr]

Just to confirm, this is only timeshift (not viewing) that you're talking about

Yes, thats correct sir I'm only using the manual control and pressing the timeshift button.

Hmmm. Have you tried Miroslav's stuttering patch? I'm just wondering whether the extra HDD IOs that Miroslav's patch fixes also affect the TV Service CPU usage. They shouldn't unless your HDD is working in PIO mode rather than UDMA mode...

p.s. No more discussion of MD*** here please. It is enough to say "encrypted" or "FTA".

Thank you both Stepko and mm1352000 for helping out. I can't really express how thankful I am.

The HDD is in UDMA mode, and yes I have tried the stuttering patch. Unfortunately that didn't change anything. :sorry:

Just to clarify:
As I have already mentioned, playback of LiveTV in MePo works OK for most of the SD channels (except Disney Playhouse - must be some codec issue), but stutters on all HD channels even though the CPU load seems to stay at 50-60%, and slightly less for SD channels. The behavior is the same for both encrypted and FTA channels. Unfortunately I have no FTA HD channels, so I can't compare CPU load with unencrypted HD channels.


Playback of ripped HD material (even 1080p) and DVDs works like a charm, I'm using the Microsoft DTV codec for both Videos and TV, and ffdshow for audio (MONOGRAM for AAC).

Regards,
PK

 

[paalkr]

Hi Stepko!

I have tried to analyse the log files according to your suggestions. Unfortunately I didn't really understand what you would like me to do. But from what I have seen there are often a gap in the sequence numbers just after the IPTVfilter passes data to the next filter.

01-02-2011 22:01:28.063 [bb8]RTP: Sending data to next filter: Len: 7896, firstTS: 0, lastTS: 590726893, firstSeqNr: 50509, lastSeqNr: 50510, continous: 0
01-02-2011 22:01:28.063 [bb8]RTP: Sending data to next filter: Len: 7896, firstTS: 0, lastTS: 590726893, continous: 0
01-02-2011 22:01:28.063 [bb8]RTP: Got unContinous packet!
01-02-2011 22:01:28.063 [bb8]RTP: Exiting Fillbuffer
01-02-2011 22:01:28.065 [bb8]Enter FillBuffer. Protokoll is 2
01-02-2011 22:01:28.066 [bb8]RTP: Enter CheckDataCanBePosted: 10240
01-02-2011 22:01:28.066 [bb8]RTP: Received bytes: 1328
01-02-2011 22:01:28.066 [bb8]RTP: Enter addPacket. SequenceNr: 51089
01-02-2011 22:01:28.067 [bb8]RTP: Enter CheckDataCanBePosted: 10240
01-02-2011 22:01:28.067 [bb8]RTP: Received bytes: 1328
01-02-2011 22:01:28.067 [bb8]RTP: Enter addPacket. SequenceNr: 51095
01-02-2011 22:01:28.069 [bb8]RTP: Enter CheckDataCanBePosted: 10240
01-02-2011 22:01:28.072 [bb8]RTP: Add dummy packet at beginning. LastSeqNr: 50510, new firstSequenceNr: 50515
01-02-2011 22:01:28.073 [bb8]RTP: Add dummy packet at beginning. LastSeqNr: 50510, new firstSequenceNr: 50514
01-02-2011 22:01:28.073 [bb8]RTP: Add dummy packet at beginning. LastSeqNr: 50510, new firstSequenceNr: 50513
01-02-2011 22:01:28.073 [bb8]RTP: Add dummy packet at beginning. LastSeqNr: 50510, new firstSequenceNr: 50512
01-02-2011 22:01:28.074 [bb8]RTP: Got unContinous packet. LastSequenceNr: 50510, currentSequenceNr: 50511
01-02-2011 22:01:28.074 [bb8]RTP: Sending data to next filter: Len: 9212, firstTS: 0, lastTS: 590727289, firstSeqNr: 50511, lastSeqNr: 50517, continous: 0
01-02-2011 22:01:28.074 [bb8]RTP: Sending data to next filter: Len: 9212, firstTS: 0, lastTS: 590727289, continous: 0
01-02-2011 22:01:28.074 [bb8]RTP: Got unContinous packet!

The first couple of seconds in each logs seems to be OK though, and that indicated packet loss due to the windsock buffer running out of space while the next filters are handling the forwarded packet, if I understood you correct. So the CPU load of the IPTVfilter it self is not the issue, but the time spent for a packet to travel the "whole graph" takes to long for the windsock buffer to hold all new packets that arrives in the mean time. Sorry, I guess this could be rephrased in a better way but my English is far from perfect.

BTW. I'm planning to building my new AMD Athlon II X4 640 (3.0 GHz) based TV server with a SSD drive this weekend, so maybe the increase in CPU power will lead to a faster processing of packets (by the other filters), and then maybe the windsock buffer don't run out of space. I will report back.

So, what happens next? Are there anything more I can contribute with on a short term?

Do you think a larger windsock buffer could help? Is that hard to implement for a testing purpose? I guess making the IPTV filter multi threaded for handling received packets while other filters are in action, is a bigger task. ;|

Regards,
PK

 

[Stepko]

AW: Re: IPTV not working

Hi all,

I just uploaded a new version of the IPTV filter. Please download and test the new version. The old version could cause lots of stuttering and picture errors when using udp or rtp. There are lots of improvements in that parts.
For more infos and download goto https://forum.team-mediaportal.com/television-mytv-frontend-tv-server-90/iptv-dvb-ip-mediaportal-support-http-rtp-udp-93708/#post716538

Stepko

 

[paalkr]

Re: AW: Re: IPTV not working

Hi all,

I just uploaded a new version of the IPTV filter. Please download and test the new version. The old version could cause lots of stuttering and picture errors when using udp or rtp. There are lots of improvements in that parts.
For more infos and download goto https://forum.team-mediaportal.com/television-mytv-frontend-tv-server-90/iptv-dvb-ip-mediaportal-support-http-rtp-udp-93708/#post716538

Stepko

Thank you very much for this new version, that have solved all my issues with the IPTV filter! I really appreciate your effort in creating the filter.

Regards,
PK

 

[Mr.Blade]

Hey,

I just tested the new filter, with m3u playlist (with udp:// channels),
and it does not work for me.


The Log is made with both the new and the old IPTV filter,
starting with the new one, and then skiftet to the old one.

 

[andre_hb]

Hi Stepko,

at the bottom is a german version of this question/text.
unten alles nochmal in deutsch, evtl. ja besser zu verstehen ;-)
Big thanx for your Filter.
The new version of MPIPTVSource.ax in the MPIPTVSource.zip has the timestamp 01.09.2010.
Is this correct ?
Because your post where the zip is edited 11-01-31 at 16:17.

I have tried this version and it works for me with t-home.
But other rtsp streams i cant getting to work.
I tried to add under the dvb-ip card a new channel.
In the url paramter i took my working videolan url (rtsp://192.168.1.23/ipcam.sdp)
in all other Parameters i wrote 1.
But it dont work.

How can i get my rtsp stream (rtsp://192.168.1.23/ipcam.sdp) to work as a tv-channel ?
Is rtsp supportet?


Nun in deutsch.

Vielen Dank für Deinen Filter.
Deinen Filter habe heruntergeladen und ausprobiert, funktioniert mit mp 1.1.3 und T-Home super.
Mir ist nur das Datum von der Datei MPIPTVSource.ax in dem MPIPTVSource.zip aufgefallen. (Datum 01.09.2010)
Nun meine Frage ob das so korrekt ist oder ob ich evtl. doch eine alte Version heruntergeladen habe?
Deine letzte Änderung von dem Posting war am 31.1.2011.

Dann bekomme ich es nicht hin einen rtsp Stream einzubinden.
Ich nutze dazu von mp die tv server configuration und probiere unter der DVB-IP Karte einen weiteren Channel anzulegen.
Als Url gebe ich rtsp://192.168.1.23/ipcam.sdp ein und alle restlcihen Parameter fülle ich mit 1.
Wenn ich nun das Preview starte dann bekomme ich die Fehlermeldung Unabletostartgraph.

Wie kann ich meinen Stream rtsp://192.168.1.23/ipcam.sdp als TV-Kanal in MP einbinden?
Ist rtsp supportet?
Oder kann ich evtl. den Stream evtl. unter Video zur Verfügung stellen (also ohne den tv-server, wäre aber schöner)?

Nice greetings von Bremen/Germany
Schöne Grüsse aus Bremen/Deutschland


André

 

[velis]

I have tested UDP functionality of the new filter from the new thread.

It seems the functionality is broken.
Out of ~10 tries, it only worked one time - I was so shocked I forgot to leave it on for a while

Here are the logs of the last 3 attempts:
1st attempt is with the MP standard filter
2nd attempt is with the new filter - working
3rd attempt is with the new filter - not working

1st and 2nd attempt are "preview" from TV Server configuration, 3rd attempt from MP client.
Service just hangs with 0% CPU usage and the UDP stream remains open (NIC still shows traffic)
I'm afraid the logs won't show much

Stepko, can you please send me the latest patch file so that I can have a go at it (though I would appreciate pointers as to why it fails...)?
It's also time I did that "nosignal" thingy I was promising two pages back