Jump to content

IPTV stream not playing from channel list


videogamingtown

Recommended Posts

videogamingtown

I have 2 iptv providers, 1 of them works fine and the other won't play in DVBViewers channel list,  The interesting thing is it does play if i click Playback> open url. For example if i literally copy and past the URL from Stream properties > Address: into the playback > open url ... it works fine. I'm not sure what's wrong because it plays my other providers channel list no problem. This is a new system so i have recently freshly installed DVBViewer.

 

In terms of the actual URL layout, both providers have a similar URL, i have tried adding .ts to end of the urls and also tried removing the port number but to no avail, yet it continues to play fine after pasting into the open url option.

 

i should add that i didn't have this problem on my last system and im using the same channel list 

Edited by videogamingtown
Link to post
Griga
vor 9 Stunden schrieb videogamingtown:

 The interesting thing is it does play if i click Playback> open url.

 

Possible reason: DVBViewer detects the content as something that can't be handled within the TS stream framework (which excludes using the URL in the channel list)  and delegates finding a solution to the DirectShow system, that for example lets the LAV Source Filter take over. Check if Settings -> Filters contains a DVB Source entry. If not, it has become a third party thing.

 

That's just a guess. Rerproducing the issue in DVBViewer debug mode and checking the server response in the DVBViewer.log will probably reveal more.

 

Link to post
videogamingtown

In settings > filters there is 1 dvb source entry. I have run through debug mode and attached the log files. I started the program tuned to the providers that works fine. I then tried to change to my alternative provider and it does not tune, i have attached the log file, could you have a look? I have also tested the older version of DVBViewer and the same thing happens. 

DVBViewer.log

Link to post
Griga

The server of the second provider immediately rejects the connection attempt with "HTTP/1.1 401 Unauthorized". Unfortunately the log doesn't show how it works with Playback -> Open, so I can't see the difference.

 

Your URLs are a bit difficult to handle for DVBViewer, because they don't indicate the media format. So first DVBViewer tries to handle them as Internet Radio (using MP3 or AAC audio) , which doesn't work out, but yields the information that the content is a transport stream (Content-Type: video/mp2t). So on second try DVBViewer can do the right thing. This means, it  connects to the server, breaks the connection due to the wrong format assumption and connects again.

 

However, since the second provider immediately rejects the first connection attempt with an error status code, there is no usable format information.

 

You can inform DVBViewer about the expected format by changing http:// to ts:// in the URLs. This works unless https:// is required and will at least speed up tuning. If it is necessary to append the information to the end, it may be better not to change the path (e.g. thisisatest.link:80/user/pass/69486.ts), because it may let the server reply with "404 Not Found", but use a query part, e.g thisisatest.link:80/user/pass/69486?whatever=.ts. Most servers will simply ignore it as long as "whatever" has no special meaning for them.

 

Link to post
videogamingtown
Posted (edited)

unfortunately that didn't work , i have gone into debug mode again and just went to playback > open url and attached the log to that.

 

Also if i add .ts to the end of the url vlc also fails to play back. eg. http://thisisatest.link:80/user/pass/69486.ts which makes me think it is not a ts format?

 

my other provider has the exact same layout of link http://thisisatest.link:80/user/pass/69486 and it works fine.

log.txt

Edited by videogamingtown
Link to post
Griga

The log shows, that opening the stream with the TS Stream framework failed (again HTTP/1.1 401 Unauthorized), and the second attempt was performed with a third party source filter (most likely LAV).

 

vor 16 Minuten schrieb videogamingtown:

Also if i add .ts to the end of the url vlc also fails to play back. eg. http://thisisatest.link:80/user/pass/69486.ts which makes me think it is not a ts format?

 

In many cases the path element of an URL can't be changed in this way without causing failure, even if the content is a TS. See my last post above.

Link to post
videogamingtown

I see, I have tested the same m3u list tonight with alternative software called ProgDvb and TVMosaic and the same channel list works in both programs , but i prefer DVBViewer and the media server.  is there anything that can be done about this? this is my favourite provider and DVBViewer is my favourite program.

Link to post
Griga

It comes down to the question why the server complains about invalid authentication credentials, though they are part of the URL (more about "401 Unauthorized" here), and why it works when you are using another client.

 

The only reason I can think of for user/password getting wrong on the way to the server are special (Non-ASCII) characters and a character coding differing from the coding expected by the server, e.g. language-specific ANSI vs. Unicode (UTF-8). Are such characters part of your user/password?

 

Link to post
videogamingtown
Quote

Please try to replace it by the percent-encoded equivalent %40

 

This works in Playback > open url within DVBViewer and vlc player after replacing @ with %40

 

It does not work when i put the same thing into channel editor

HTTP/1.1 401 Unauthorized

 

could it be the . ? 🥺

 

Link to post
Griga
vor 2 Minuten schrieb videogamingtown:

could it be the . ? 

 

It should be no problem:

 

https://stackoverflow.com/questions/6777274/can-urls-contain-dots-in-the-path-part

 

I really wonder which subtle difference makes it work in other clients. A non-ASCII character would have been a good explanation, because DVBViewer still uses a language specific encoding, though UTF-8 has become a de facto web standard for such characters, but this has been ruled out now.

 

Of course the user agent string in the HTTP request header is different:

 

Request Header   
GET /user/password/92 HTTP/1.1
Host: thisanother.provider
User-Agent: DVBViewer Pro 6.1

 

but why should the server exclude certain user agents?

 

Another thing: DVBViewer omits port 80 in the Host part of the header, because usually there is no need to transmit the HTTP standard port. But even if the server is unhappy with it, "401 Unauthorized" is no appropriate response.

 

Link to post
Griga

Some tests, using the DVBViewer Media Server under debugger control for viewing the HTTP requests of different clients, plus the following URL (working on my PC), made as similar as possible to your URLs:

 

http://medion-pc:80/user@mail.com/password/upnp/channelstream/7

 

DVBViewer Request:

GET /user@mail.com/password/upnp/channelstream/7 HTTP/1.1
Host: medion-pc
User-Agent: DVBViewer Pro 6.1

VLC Request:

GET /user@mail.com/password/upnp/channelstream/7 HTTP/1.1
Host: medion-pc:80
Accept: */*
Accept-Language: de
User-Agent: VLC/3.0.8 LibVLC/3.0.8
Range: bytes=0-

LAV Source Filter Request:

GET /user@mail.com/password/upnp/channelstream/7 HTTP/1.1
User-Agent: Lavf/58.26.101
Accept: */*
Range: bytes=0-
Connection: close
Host: medion-pc:80
Icy-MetaData: 1

 

The DVBViewer Media Server accepted all these HTTP requests quite happily, without checking user/password - they were irrelevant in in this test scenario - and delivered the requested TV stream. But what are the differences? Obviously the port indication, user agent string, and some additional header fields that DVBViewer doesn't provide.

 

Within the TS Stream framework HTTP header fields can be changed or added in DVBViewer (except the Host:Port field) by appending a special query part to the URL. The following one lets DVBViewer behave almost like the VLC:

 

ts://medion-pc:80/user@mail.com/password/upnp/channelstream/7?addhdr=Accept: */*%0d%0aUser-Agent: VLC/3.0.8 LibVLC/3.0.8%0d%0aRange: bytes=0-

 

ts:// specifies the media format and avoids the attempt to receive internet radio first. The part beginning with ?addhdr=... is not sent to the server, but processed by DVBViewer internally. It specifies the to be changed/added request header fields, separated by %0d%0a (= carriage return and line feed). The result is a

 

Modified DVBViewer Request:

GET /user@mail.com/password/upnp/channelstream/7 HTTP/1.1
Host: medion-pc
Accept: */*
User-Agent: VLC/3.0.8 LibVLC/3.0.8
Range: bytes=0-

Please apply this modification to your URL and try...

 

Link to post
videogamingtown

Incredible ! it works, thanks so much for your extra work and providing a solution!

Link to post
Griga

Now it would be interesting to know which part does the trick. For sure it isn't the ts://, because the server doesn't see it. Please try the changed/added header fields one after the other:

 

?addhdr=Accept: */*

?addhdr=Range: bytes=0-

 

If one of these is enough to make it work, DVBViewer should perhaps add it by default

 

?addhdr=User-Agent: VLC/3.0.8 LibVLC/3.0.8

 

If only this addition lets the server serve, it could mean that DVBViewer is explicitely excluded (black-listed) by the provider, maybe because it's known as recording software.

 

Link to post
videogamingtown
Posted (edited)

it seems only ?addhdr=User-Agent: VLC/3.0.8 LibVLC/3.0.8 will work 

 

?addhdr=Accept: */* or 

?addhdr=Range: bytes=0-  result in the earlier HTTP unauthorized error 

Edited by videogamingtown
Link to post
Griga
vor 17 Stunden schrieb videogamingtown:

it seems only ?addhdr=User-Agent: VLC/3.0.8 LibVLC/3.0.8 will work 

 

It really looks like the provider doesn't want DVBViewer clients. However, investigating the pattern behind it would require some criminalistic energy and experiments with user agent variations. Maybe the provider excludes all user agents that contain "DVBViewer" as substring, or it only accepts certain known user agents... anyway, you have a solution, and that's fine :)

 

Link to post
  • 5 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...