PDA

View Full Version : Live365 continuing problem



Roger Mitchell
2004-12-11, 05:18
For Jim (et al): Still unable to get Live 365 working through slimserver
although if I enter a stream address manually it works. Here is a copy of
the log. I do appreciate your work on this Jim; I know that there are only a
few of us that seem to have this problem. BTW, this is running on the latest
nightly on a Windows XP SP2 Pro system with 1Gb Ram, Intel 3.2Ghz HT:

2004-12-11 11:09:43.2969 Mode datetime not found, using default

2004-12-11 11:09:55.1288 Logging in HiTowerUK

2004-12-11 11:09:55.5478 Live365 logged in: hitoweruk:57ltkxv7HXrB2

2004-12-11 11:10:08.6913 Live365.ChannelMode URL:
live365://www.live365.com/play/gruenewithenvy?sessionid=hitoweruk:57ltkxv7HX
rB2

2004-12-11 11:10:08.6918 Non-URL passed to updateCacheEntry::info
(live365://www.live365.com/play/gruenewithenvy?sessionid=hitoweruk:57ltkxv7H
XrB2)

2004-12-11 11:10:08.6924 Backtrace:



frame 0: Slim::Music::Info::updateCacheEntry (/PerlApp/Slim/Music/Info.pm
line 937)

frame 1: Slim::Music::Info::setContentType
(C:/PROGRA~1/SLIMSE~1/server/Plugins/Live365.pm line 739)

frame 2: Plugins::Live365::playOrAddCurrentStation
(C:/PROGRA~1/SLIMSE~1/server/Plugins/Live365.pm line 1195)

frame 3: Plugins::Live365::__ANON__ (/PerlApp/Slim/Hardware/IR.pm line
588)

frame 4: Slim::Hardware::IR::executeButton
(/PerlApp/Slim/Control/Command.pm line 209)

frame 5: Slim::Control::Command::execute (/PerlApp/Slim/Hardware/IR.pm
line 612)

frame 6: Slim::Hardware::IR::processCode (/PerlApp/Slim/Hardware/IR.pm
line 486)

frame 7: Slim::Hardware::IR::holdCode (/PerlApp/Slim/Hardware/IR.pm line
412)

frame 8: Slim::Hardware::IR::processIR (/PerlApp/Slim/Control/Command.pm
line 209)

frame 9: Slim::Control::Command::execute (/PerlApp/Slim/Hardware/IR.pm
line 65)

frame 10: Slim::Hardware::IR::idle (slimserver.pl line 431)

frame 11: main::idle (slimserver.pl line 397)

frame 12: main::main (slimserver.pl line 61)

frame 13: PerlSvc::Interactive (perlsvc line 1203)

frame 14: PerlSvc::_interactive (slimserver.pl line 0)

frame 15: (eval) (slimserver.pl line 0)



2004-12-11 11:10:08.6949 Non-URL passed to updateCacheEntry::info
(live365://www.live365.com/play/gruenewithenvy?sessionid=hitoweruk:57ltkxv7H
XrB2)

2004-12-11 11:10:08.6955 Backtrace:



frame 0: Slim::Music::Info::updateCacheEntry (/PerlApp/Slim/Music/Info.pm
line 951)

frame 1: Slim::Music::Info::setTitle
(C:/PROGRA~1/SLIMSE~1/server/Plugins/Live365.pm line 740)

frame 2: Plugins::Live365::playOrAddCurrentStation
(C:/PROGRA~1/SLIMSE~1/server/Plugins/Live365.pm line 1195)

frame 3: Plugins::Live365::__ANON__ (/PerlApp/Slim/Hardware/IR.pm line
588)

frame 4: Slim::Hardware::IR::executeButton
(/PerlApp/Slim/Control/Command.pm line 209)

frame 5: Slim::Control::Command::execute (/PerlApp/Slim/Hardware/IR.pm
line 612)

frame 6: Slim::Hardware::IR::processCode (/PerlApp/Slim/Hardware/IR.pm
line 486)

frame 7: Slim::Hardware::IR::holdCode (/PerlApp/Slim/Hardware/IR.pm line
412)

frame 8: Slim::Hardware::IR::processIR (/PerlApp/Slim/Control/Command.pm
line 209)

frame 9: Slim::Control::Command::execute (/PerlApp/Slim/Hardware/IR.pm
line 65)

frame 10: Slim::Hardware::IR::idle (slimserver.pl line 431)

frame 11: main::idle (slimserver.pl line 397)

frame 12: main::main (slimserver.pl line 61)

frame 13: PerlSvc::Interactive (perlsvc line 1203)

frame 14: PerlSvc::_interactive (slimserver.pl line 0)

frame 15: (eval) (slimserver.pl line 0)

Slim
2004-12-12, 07:13
> For Jim (et al): Still unable to get Live 365 working through slimserver
> although if I enter a stream address manually it works. Here is a copy of
> the log. I do appreciate your work on this Jim; I know that there are only
> a
> few of us that seem to have this problem. BTW, this is running on the
> latest
> nightly on a Windows XP SP2 Pro system with 1Gb Ram, Intel 3.2Ghz HT:
>
> 2004-12-11 11:09:43.2969 Mode datetime not found, using default
>
> 2004-12-11 11:09:55.1288 Logging in HiTowerUK
>
> 2004-12-11 11:09:55.5478 Live365 logged in: hitoweruk:57ltkxv7HXrB2
>
> 2004-12-11 11:10:08.6913 Live365.ChannelMode URL:
> live365://www.live365.com/play/gruenewithenvy?sessionid=hitoweruk:57ltkxv7HX
> rB2
>
> 2004-12-11 11:10:08.6918 Non-URL passed to updateCacheEntry::info
>

I had this problem to, and it is to do with the URL being used. It should
start http:// but it is starting live365://

Jim knows about this and has sent a fix to be included in a nightly. I
agree, this is fantastic work by Jim and big htanks to him for sorting
this problem out.

eg. live365://www.live365.com instead of http://www.live365.com

-- Stuart



Random Thought:
---------------

Jim
2004-12-12, 09:55
Slim wrote:
>>For Jim (et al): Still unable to get Live 365 working through slimserver
>>although if I enter a stream address manually it works. Here is a copy of
>>the log. I do appreciate your work on this Jim; I know that there are only
>>a
>>few of us that seem to have this problem. BTW, this is running on the
>>latest
>>nightly on a Windows XP SP2 Pro system with 1Gb Ram, Intel 3.2Ghz HT:
>>
>>2004-12-11 11:09:43.2969 Mode datetime not found, using default
>>
>>2004-12-11 11:09:55.1288 Logging in HiTowerUK
>>
>>2004-12-11 11:09:55.5478 Live365 logged in: hitoweruk:57ltkxv7HXrB2
>>
>>2004-12-11 11:10:08.6913 Live365.ChannelMode URL:
>>live365://www.live365.com/play/gruenewithenvy?sessionid=hitoweruk:57ltkxv7HX
>>rB2
>>
>>2004-12-11 11:10:08.6918 Non-URL passed to updateCacheEntry::info
>>
>
>
> I had this problem to, and it is to do with the URL being used. It should
> start http:// but it is starting live365://
>
> Jim knows about this and has sent a fix to be included in a nightly. I
> agree, this is fantastic work by Jim and big htanks to him for sorting
> this problem out.
>
> eg. live365://www.live365.com instead of http://www.live365.com

I know you mean well, and I appreciate your interest in being part of
the solution. Please, please, please don't guess at a problem when you
don't understand the underlying code; it only serves to confuse people.

The Live365 plugin implements a custom protocol, called live365, to
manage the timers that periodically retrieve the currently playing song.
I haven't gotten a chance to debug this problem fully yet, but having
live365:// on the front of a URL is correct.

Jim

Jim
2004-12-13, 20:16
Roger Mitchell wrote:
> For Jim (et al): Still unable to get Live 365 working through slimserver
> although if I enter a stream address manually it works. Here is a copy
> of the log. I do appreciate your work on this Jim; I know that there are
> only a few of us that seem to have this problem. BTW, this is running on
> the latest nightly on a Windows XP SP2 Pro system with 1Gb Ram, Intel
> 3.2Ghz HT:

No luck so far.
Please send similar output with both --d_plugins and --d_source turned on.

Cheers,
Jim

dp
2004-12-18, 19:00
I too have never been able to get Live 365 to play from the Internet
Radio menu even though tI am logged in. I have run a debug log and find
that the server is trying to request a URL that starts
"live365://www.live365.com/play/gersch?sessionid=...." The debug log
helpfully suggests that this should be starting with "http://" or similar.

If I paste the live365:// url shown in the log into Foobar it gives an
error, but if I use the same URL and substiutute http:// for live365://
the stream plays just fine.

I looked at the pm file and found a couple of places where the URL is
referenced but my amateur hacking did not manage to get it to work
correctly.

Can it be that the live365:// url works for most people but somehow
doesn't for others? I am running XP SP1.

Jim wrote:

> Roger Mitchell wrote:
>
>> For Jim (et al): Still unable to get Live 365 working through
>> slimserver although if I enter a stream address manually it works.
>> Here is a copy of the log. I do appreciate your work on this Jim; I
>> know that there are only a few of us that seem to have this problem.
>> BTW, this is running on the latest nightly on a Windows XP SP2 Pro
>> system with 1Gb Ram, Intel 3.2Ghz HT:
>
>
> No luck so far.
> Please send similar output with both --d_plugins and --d_source turned
> on.
>
> Cheers,
> Jim
>
>

Roger Mitchell
2004-12-19, 02:39
No, I think you're barking up the wrong tree. Jim explained in an
earlier thread that this is something to do with the protocol and it
is in fact correct. I think that our problem is shared among a small
minority of users and Jim is trying to debug it. Doesn't seem to be
happening very quickly so I am not sure how much time Jim has got to
re-look at it but it a great shame for the few of us that have to
"suffer in silence" (as far as Live 365 is concerned!).

Best regards
Roger


On Sun, 19 Dec 2004 10:00:38 +0800, dp <dpilgrim (AT) exasia (DOT) net> wrote:
> I too have never been able to get Live 365 to play from the Internet
> Radio menu even though tI am logged in. I have run a debug log and find
> that the server is trying to request a URL that starts
> "live365://www.live365.com/play/gersch?sessionid=...." The debug log
> helpfully suggests that this should be starting with "http://" or similar.
>
> If I paste the live365:// url shown in the log into Foobar it gives an
> error, but if I use the same URL and substiutute http:// for live365://
> the stream plays just fine.
>
> I looked at the pm file and found a couple of places where the URL is
> referenced but my amateur hacking did not manage to get it to work
> correctly.
>
> Can it be that the live365:// url works for most people but somehow
> doesn't for others? I am running XP SP1.
>
> Jim wrote:
>
> > Roger Mitchell wrote:
> >
> >> For Jim (et al): Still unable to get Live 365 working through
> >> slimserver although if I enter a stream address manually it works.
> >> Here is a copy of the log. I do appreciate your work on this Jim; I
> >> know that there are only a few of us that seem to have this problem.
> >> BTW, this is running on the latest nightly on a Windows XP SP2 Pro
> >> system with 1Gb Ram, Intel 3.2Ghz HT:
> >
> >
> > No luck so far.
> > Please send similar output with both --d_plugins and --d_source turned
> > on.
> >
> > Cheers,
> > Jim
> >
> >

Vic
2004-12-19, 07:56
On Sun, Dec 19, 2004 at 09:39:21AM +0000, Roger Mitchell wrote:
> No, I think you're barking up the wrong tree. Jim explained in an
> earlier thread that this is something to do with the protocol and it
> is in fact correct. I think that our problem is shared among a small
> minority of users and Jim is trying to debug it. Doesn't seem to be
> happening very quickly so I am not sure how much time Jim has got to
> re-look at it but it a great shame for the few of us that have to
> "suffer in silence" (as far as Live 365 is concerned!).

A couple of ideas (coming into this late, so apologies if it's been covered):

The start of a URL basically indicates the protocol to be used for that
connection -- same way that "http://" means "use the HTTP protocol, and
make a TCP connection on port 80 to do it unless the port is overriden in
the URL". This translation from URL 'prefix' to protocol and port has to
be defined someplace -- perhaps on the systems that are having trouble, this
definition is missing. I just looked in both my services file and
mime.types, and there's nothing for 'live365' (of course that probably just
means that the magic is someplace else).

The fact that for someone out there changing "live365://" to "http://"
made it work tells me that Live365 is just using the HTTP protocol on
TCP port 80. So maybe using "live365://" is *supposed* to work, but changing
the request to "http://" might be a more portable solution. Of course this
might break other parts of the Live365 support... :(

Another possibility, since it looks like Live365 works over the HTTP port,
is that the people having trouble are with ISPs that use transparent proxying
of HTTP traffic and Live365 can't deal with that. Unlikely (since the work-
around wouldn't work if that were the case) but anything's possible.

Cheers,
Vic

Jim
2004-12-19, 10:17
Vic wrote:
> On Sun, Dec 19, 2004 at 09:39:21AM +0000, Roger Mitchell wrote:
>
>>No, I think you're barking up the wrong tree. Jim explained in an
>>earlier thread that this is something to do with the protocol and it
>>is in fact correct. I think that our problem is shared among a small
>>minority of users and Jim is trying to debug it. Doesn't seem to be
>>happening very quickly so I am not sure how much time Jim has got to
>>re-look at it but it a great shame for the few of us that have to
>>"suffer in silence" (as far as Live 365 is concerned!).
>
>
> A couple of ideas (coming into this late, so apologies if it's been covered):
>
> The start of a URL basically indicates the protocol to be used for that
> connection -- same way that "http://" means "use the HTTP protocol, and
> make a TCP connection on port 80 to do it unless the port is overriden in
> the URL". This translation from URL 'prefix' to protocol and port has to
> be defined someplace -- perhaps on the systems that are having trouble, this
> definition is missing. I just looked in both my services file and
> mime.types, and there's nothing for 'live365' (of course that probably just
> means that the magic is someplace else).
>
> The fact that for someone out there changing "live365://" to "http://"
> made it work tells me that Live365 is just using the HTTP protocol on
> TCP port 80. So maybe using "live365://" is *supposed* to work, but changing
> the request to "http://" might be a more portable solution. Of course this
> might break other parts of the Live365 support... :(
>
> Another possibility, since it looks like Live365 works over the HTTP port,
> is that the people having trouble are with ISPs that use transparent proxying
> of HTTP traffic and Live365 can't deal with that. Unlikely (since the work-
> around wouldn't work if that were the case) but anything's possible.

I'm going to explain this in some detail so that people searching the
archives can find it, and to hopefully clear up the confusion.

The live365 protocol handler (starting at the line "package
Plugins::Live365::ProtocolHandler" in Live365.pm) is a derived class
from Slim::Player::Protocols::HTTP. Once the protocol handler is
registered, live365:// URLs have meaning to Slimserver, it knows what to
do with that protocol. The handler does two things...

When you request a station via Live365 (via http://live365.com/play/),
it redirects you to another server and another port. You'll find details
of this in the "Live365 station really at:" message if you run with
--d_plugins. That "real" address is read and sent to the parent class
(the stock http protocol handler) for playback.

The redirected address provides the MP3 stream, but sets the ICY headers
to the station name, not the currently playing song, so you'd see the
station title and nothing else. The handler starts a timer loop that
periodically polls http://live365.com/pls/front for the current playlist
of the station you're listening to, then sets that title locally so it
displays on the Squeezebox.

Yes, you can listen to Live365 via HTTP if you don't want song titles
displayed. The thing is, specific to Roger's problem, I'm having
difficulty recreating the problem locally, and the logs he sends, while
I'm sure are truthful, aren't sane to my understanding of Slimserver
flow overall. KDF, Dean, and others have commented that his installation
isn't behaving normally as well.

I'm still engaged on the issue, it's just still a mystery.

J

Aaron Zinck
2004-12-19, 16:25
It's not working with me, either, Jim. When I find a station and press play
I see nothing happen on the screen--no response. The box isn't frozen, it
just doesn't do anything. When I go to "now playing" there's nothing
present. I'm running windows 2000 and slimserver 5.4 (dec. 3 nightly).
Don't know if more info would be helpful in determining a pattern but here's
my log:

2004-12-19 18:17:38.8758 Logging in azinck3
2004-12-19 18:17:40.3115 Live365 logged in: azinck3:535rTFAVshbyQ
2004-12-19 18:17:56.8206 Live365.ChannelMode URL:
live365://www.live365.com/play/kkjz1?sessionid=azinck3:535rTFAVshbyQ
2004-12-19 18:17:56.8213 Non-URL passed to updateCacheEntry::info
(live365://www.live365.com/play/kkjz1?sessionid=azinck3:535rTFAVshbyQ)
2004-12-19 18:17:56.8220 Backtrace:

frame 0: Slim::Music::Info::updateCacheEntry (/PerlApp/Slim/Music/Info.pm
line 937)
frame 1: Slim::Music::Info::setContentType (C:/Program
Files/SlimServer/server/Plugins/Live365.pm line 739)
frame 2: Plugins::Live365::playOrAddCurrentStation (C:/Program
Files/SlimServer/server/Plugins/Live365.pm line 1195)
frame 3: Plugins::Live365::__ANON__ (/PerlApp/Slim/Hardware/IR.pm line
546)
frame 4: Slim::Hardware::IR::executeButton
(/PerlApp/Slim/Control/Command.pm line 209)
frame 5: Slim::Control::Command::execute (/PerlApp/Slim/Hardware/IR.pm
line 570)
frame 6: Slim::Hardware::IR::processCode (/PerlApp/Slim/Hardware/IR.pm
line 429)
frame 7: Slim::Hardware::IR::releaseCode (/PerlApp/Slim/Hardware/IR.pm
line 327)
frame 8: Slim::Hardware::IR::checkRelease (/PerlApp/Slim/Utils/Timers.pm
line 52)
frame 9: Slim::Utils::Timers::checkTimers (slimserver.pl line 426)
frame 10: main::idle (slimserver.pl line 40)
frame 11: PerlSvc::Startup (perlsvc line 1201)
frame 12: PerlSvc::_startup (slimserver.pl line 0)
frame 13: (eval) (slimserver.pl line 0)



"Jim" <jim1128 (AT) comcast (DOT) net> wrote in message
news:cq4d3m$m6s$1 (AT) sea (DOT) gmane.org...
> Vic wrote:
> > On Sun, Dec 19, 2004 at 09:39:21AM +0000, Roger Mitchell wrote:
> >
> >>No, I think you're barking up the wrong tree. Jim explained in an
> >>earlier thread that this is something to do with the protocol and it
> >>is in fact correct. I think that our problem is shared among a small
> >>minority of users and Jim is trying to debug it. Doesn't seem to be
> >>happening very quickly so I am not sure how much time Jim has got to
> >>re-look at it but it a great shame for the few of us that have to
> >>"suffer in silence" (as far as Live 365 is concerned!).
> >
> >
> > A couple of ideas (coming into this late, so apologies if it's been
covered):
> >
> > The start of a URL basically indicates the protocol to be used for that
> > connection -- same way that "http://" means "use the HTTP protocol, and
> > make a TCP connection on port 80 to do it unless the port is overriden
in
> > the URL". This translation from URL 'prefix' to protocol and port has
to
> > be defined someplace -- perhaps on the systems that are having trouble,
this
> > definition is missing. I just looked in both my services file and
> > mime.types, and there's nothing for 'live365' (of course that probably
just
> > means that the magic is someplace else).
> >
> > The fact that for someone out there changing "live365://" to "http://"
> > made it work tells me that Live365 is just using the HTTP protocol on
> > TCP port 80. So maybe using "live365://" is *supposed* to work, but
changing
> > the request to "http://" might be a more portable solution. Of course
this
> > might break other parts of the Live365 support... :(
> >
> > Another possibility, since it looks like Live365 works over the HTTP
port,
> > is that the people having trouble are with ISPs that use transparent
proxying
> > of HTTP traffic and Live365 can't deal with that. Unlikely (since the
work-
> > around wouldn't work if that were the case) but anything's possible.
>
> I'm going to explain this in some detail so that people searching the
> archives can find it, and to hopefully clear up the confusion.
>
> The live365 protocol handler (starting at the line "package
> Plugins::Live365::ProtocolHandler" in Live365.pm) is a derived class
> from Slim::Player::Protocols::HTTP. Once the protocol handler is
> registered, live365:// URLs have meaning to Slimserver, it knows what to
> do with that protocol. The handler does two things...
>
> When you request a station via Live365 (via http://live365.com/play/),
> it redirects you to another server and another port. You'll find details
> of this in the "Live365 station really at:" message if you run with
> --d_plugins. That "real" address is read and sent to the parent class
> (the stock http protocol handler) for playback.
>
> The redirected address provides the MP3 stream, but sets the ICY headers
> to the station name, not the currently playing song, so you'd see the
> station title and nothing else. The handler starts a timer loop that
> periodically polls http://live365.com/pls/front for the current playlist
> of the station you're listening to, then sets that title locally so it
> displays on the Squeezebox.
>
> Yes, you can listen to Live365 via HTTP if you don't want song titles
> displayed. The thing is, specific to Roger's problem, I'm having
> difficulty recreating the problem locally, and the logs he sends, while
> I'm sure are truthful, aren't sane to my understanding of Slimserver
> flow overall. KDF, Dean, and others have commented that his installation
> isn't behaving normally as well.
>
> I'm still engaged on the issue, it's just still a mystery.
>
> J