TV streams added to Video category in orbiter

[itsmeok]

I am still curious why played TV streams are added to the Video category in the orbiter. This is not the case with music streams. You will not see them back in the Audio category. Can I stop the addition of the TV streams to the Video category ?

Secondly I heard that there are issues with storing TV streams that do not have a file extention and that start with an IP address. The problem I heard was that the link is not stored correct in the DB.

Who can shine a light on this for me.

[jeangot]

Here is an example of such a stream that cannot be added properly in LMCE: http://87.118.126.208:2008

[tschak909]

*hmm* fellas...

This is due to the way the media handler currently functions. IPTV stuff will ALWAYS be dealt with as StoredVideo. Look at the code for the Media_PlugIn.

If you want an IPTV specific media type that behaves like TV, a media type will have to be done for it, and will have to be intercepted by MythTV or VDR Plugin in much the same was as the Xine Plugin intercepts and diverts play media commands to MPlayer_Player (look at Xine_Plugin's source and grep for mplayer).

-Thom

[jeangot]

Thom,
my problem here is not that LMCE stores these as media files, that's the way it works and that's just fine with me.My problem is thet the above stream gets added to the File Db like this:
Path mms:
Filename 87.118.126.208:2008

When I then try to play it back, LMCE concatenates these fields as mms:/87.118.126.208:2008 and that of course fails. Because there is technically no path in this case, i think it gets confused when storing it in in the db and is missin one /. If I add an extra / in the Path field (like this mms:/)  in the Db entry it works fine, but only till the next reload. The some portion of the code parses all th entries and normalizes this one back to mms:

I had asked in the past what part of the code is responsible for this, so that I could have a look and possibly fix it for the particular case of mms:// and http:// without path, but I had not received a reply..

Jean

[tschak909]

start in src/Media_Plugin

also look at the Xine_Plugin and the Xine_Player.

-Thom.

[colinjones]

Thom,
my problem here is not that LMCE stores these as media files, that's the way it works and that's just fine with me.My problem is thet the above stream gets added to the File Db like this:
Path mms:
Filename 87.118.126.208:2008

When I then try to play it back, LMCE concatenates these fields as mms:/87.118.126.208:2008 and that of course fails. Because there is technically no path in this case, i think it gets confused when storing it in in the db and is missin one /. If I add an extra / in the Path field (like this mms:/)  in the Db entry it works fine, but only till the next reload. The some portion of the code parses all th entries and normalizes this one back to mms:

I had asked in the past what part of the code is responsible for this, so that I could have a look and possibly fix it for the particular case of mms:// and http:// without path, but I had not received a reply..

Jean

Jean

If it is just because it is dotted octets rather than an FQDN name, you can work around this by putting an entry in your hosts file, then replacing the dotted octets with that entry.

(but don't forget to look at the source and see if you can fix it properly - before Thom bites my head off for suggesting duct tape! )

[jeangot]

I have been looking at this further to try and find a suitable solution, even possibly to make an admin page to add/delete streams.
First I found that Shoutcast streams have an equivalent that includes a filename.
So http://87.118.126.208:2008 is actually the same as http://87.118.126.208:2008/listen.pls

When I use the second form, there are no more problems with missing / in the DB. But now I have the following problem:
The stream plays fine in KDE desktop like this:
xine http://87.118.126.208:2008/listen.pls

However when I add the above location to the database (going through a media scenario) and then try to play it via the system, I get the following error:

05      02/05/09 8:46:22.072            Xine_Player::CMD_Play_Media() called for id 1010 filename: http://87.118.126.208:2008/listen.pls () <0xb6c51b90>
01      02/05/09 8:46:25.089            FindFirstRelatedDeviceOfCategory 163 dev 205 never registered <0xb6c51b90>
05      02/05/09 8:46:25.089            Xine_Player::CMD_Play_Media() stopping PSS failed - no PSS found or it is stuck <0xb6c51b90>
05      02/05/09 8:46:25.151            Xine_Player::EVENT_Playback_Completed(streamID=1008) <0xb6c51b90>
05      02/05/09 8:46:25.152            XineStreamEventListener called on non-initialized stream - aborting command <0xb22dfb90>
05      02/05/09 8:46:25.472            Destroyed stream with ID=1008 <0xb6c51b90>
05      02/05/09 8:46:25.573            Created new stream with ID=1010 deint 0  100 0 <0xb6c51b90>
05      02/05/09 8:46:25.573            Xine_Player::CMD_Play_Media() set stream 1010 as last rendering to screen. <0xb6c51b90>
05      02/05/09 8:46:25.573            Xine_Player::CMD_Play_Media() called for id 1010 filename: http://87.118.126.208:2008/listen.pls () with corresponding stream 0x8706968. <0xb6c51b90>
05      02/05/09 8:46:25.573            Opening media without chapters/title position: http://87.118.126.208:2008/listen.pls  <0xb6c51b90>
05      02/05/09 8:46:25.574            Playback (Connecting HTTP server...) is at 0 <0xaf58bb90>
05      02/05/09 8:46:26.004            Opening media FAILED <0xb6c51b90>
05      02/05/09 8:46:26.004            Xine_Stream::OpenMedia failed! Aborting! <0xb6c51b90>
05      02/05/09 8:46:26.005            Xine_Player::CMD_Play_Media() Failed to open media <0xb6c51b90>
05      02/05/09 8:46:27.003            Xine_Player::CMD_Play_Media() ended for filename: http://87.118.126.208:2008/listen.pls with stream 0x8706968. <0xb6c51b90>
05      02/05/09 8:46:27.005            Xine_Player::CMD_Stop_Media() with corresponding stream id 1010 0x8706968. <0xb6c51b90>
05      02/05/09 8:46:27.005            Xine_Stream::changePlaybackSpeed no running seekers found <0xb6c51b90>
05      02/05/09 8:46:27.006            Xine_Player::EVENT_Playback_Completed(streamID=1010) <0xb6c51b90>
05      02/05/09 8:46:27.007            XineStreamEventListener called on non-initialized stream - aborting command <0xaf58bb90>
05      02/05/09 8:46:27.256            Closed stream AV with ID=1010 <0xb6c51b90>

Does anyone have any suggestions why Xine_Player doesn't like playing this when Xine can? I tried also with mms:// instead of http:// but no improvements.

Colin, are you saying that the system cannot playback something that looks like an IP and not like a FQDN, or was your comment just for cosmetic reasons?

Jean

EDIT: this is all about audio streams now by the way, not video yet

[colinjones]

hmm. I thought you were saying that it doesn't like media streams that are described as IP addresses, and only works when they are FQDNs? If so, then my suggestion allows you to pretend it is an FQDN so that you can play it.... otherwise I have misunderstood what the problem is.

BTW, the article on setting up Internet Radio specifically says that you can't use pls files, you need to extract the URL from the pls file and use that, hence your problem...

[jeangot]

Colin,

thanks. The problem was indeed not about the IP addresses.
Do we know why it doesn't like pls files when Xine itself has no problem with them?

If I remove the PLS file, then I'm back to http://87.118.126.208:2008 which doesn't play for a different reason: because there is no filename.

Jean

[colinjones]

Jean - confused now! Although I can see some of the source of it... it was actually itsmeok that said there was a problem with the IP address (and that was for video anyway).

Why doesn't your stream work? Mine work perfectly without a file name just by following the wiki article. eg http://radio.internode.on.net:8030/ (this won't work outside my ISP, but it works fine for me, plus many others) Are you not trying to add this as a scenario?

[jeangot]

Colin,

sorry I wasn't perfectly clear: yes I think it works when adding it as a scenario, but that is not practical to add dozens of stations (or hundreds). So I am trying to get this added as a normal file, so that it can be played from a Playlist for example. The Playlists are accessible via a direct button on any orbiter, and there you could easily create one playlist per station with a nice logo, or even put stations of similar music style in the same playlist.
I don't have a problem playing a stream with a filename that is not pls from a playlist (at least I think so). I do it everyday for example to watch a streaming newscast.  But when there is no filename or the pls filename, it doesn't work anymore.
There are probably several solutions to this problem. One would be if anyone knows why PLS doesn't work and I can fix it. Or why doesn't it play something with no filename at all (for this I can imagine why: it doesn't know what to do with it without a filetype).

Jean

[colinjones]

I see now!

For what its worth, I don't think there is a problem specifically with .pls files, this is a red herring. I would need to look at the other URLs you have to be sure, but I think the ones you have that have filenames that don't end in .pls are simply web server placeholders and the actual MIME type is an audio stream, and so is the content. So when Xine "gets" it, it is told it is a media stream (which it can handle) and then the audio starts streaming to it and so it plays it OK.

But a .pls file is exactly that - it isn't an audio stream nor does its MIME type say that it is. A .pls file contains a list of the actual URLs for the stream (in other words it is indirect thru the pls file). So when you "get" this file, you are told it is a playlist file, you down load it, and then need to be able to parse it, extract the first actual stream URL, connect to that, get told that its MIME type is a stream, then start playing it....

The missing piece here is it seems that LMCE doesn't know that it has to treat this as a playlist file, parse it then connect to the stream, it just tries to download the file, but a file of MIME type "text" or whatever, it doesn't know how to deal with. I thing, from memory, that .asf files are indirect like this, too. "Announcement" files? So presuming that LMCE can't parse those either, then any link to those shouldn't work either even though there is a filename in the URL....

Hope that makes sense, I'm trying to say that I don't think there is something specific about .pls files, any file that does this indirect/redirect should file too unless LMCE specifically knows how to handle it.

As for the underlying problem, it certainly looks like you are right, its a parsing problem. I can't think of any obvious way of fooling it into parsing it correctly...

[jeangot]

Colin,

you;re right about the pls files (and asf). They're actually text files that you can open and there is some information in there like title, genre, and the address of the stream itself.
The thing is, xine is very happy to parse the file and listen to the stream when you run:
xine http://87.118.126.208:2008/listen.pls
in KDE.

So are you thinking that this "parsing" feature is something in xine (the player), and not xinelib (the backend), and that Xine_Player which is LMCE's equivalent of xine using xinelib (same backend), does not have this feature implemented?

That's possible of course. In that case it may be easier to teach Xine_Player what to do with files without extension (which is what I have if I feed the stream directly without pls file) rather than teaching it to parse the pls and then teaching it to reach the extensionless stream anyway...
It's no problem for a normal user to open the pls file and read the stream location, and I could even take a stab at a php page that does this by itself and inserts the actual stream location in the LMCE DB, but first we need to have LMCE actually play these streams.

Jean

[colinjones]

That's precisely what I was thinking. Seems logical that the Xine GUI in KDE is responsible for allowing you to browse and select files (ie nothing to do with xinelib.. they are media playing libraries) and presumably dealing with and parsing the .pls files as well.... after all why would xinelib know how to do this, they aren't media.

I agree, it is likely much easier to teach xine wrapper in LMCE how to deal with the URLs when there is no file, than teach it how to parse a pls file (although the code for this must be in the Xine sources somewhere). That's the parsing I meant, parsing of the db entries.

(btw, Turkish pop music at 24kbps??!!)

[jeangot]

Colin,
thanks, will look at the code again under this new light and see if I can find anything. Not being fluent in C++ doesn't help unfortunately...

I liked Turkish music when I went to Turkey once. We don't hear that much in the US so I figured let's take advantage of LMCE to get access to what we normally don't get access to. This stream in particular is just randomly chosen on shoutcast for this test, I'm sure there is better quality ones available...

Jean