Please provide debug logs from plugin.sirius

All it requires is to just try it.  It's 100% reproducible as far as I know.  However, if you really cant do the log for the plugin yourself, I will upload it later today.

Michael: We need to see the errors YOU are experiencing, that is why I requested the log file.

Created attachment 4681 [details]
plugin.sirius (debug log)

Please find a debug log attached.  I attempted to PLAY 3 Sirius Radio Channels.  On softsqueeze, the display shows as playing.  But, there's no audio.  I dont have any problems with slacker nor pandora plugins.

I have tried both proxied and direct connection types under player settings for audio.

Alan: Your thoughts on this one

Michael: thank you for the log, it helps.  Can I ask you for 1 more log please, this time, player.source set to Debug.

Created attachment 4683 [details]
player.source (log) debug

Richard:  Per your request, here's the debug log you asked for.  It contains respective sirius plugin debug as well.  In this log, all I did was try to PLAY 3 sirius radio stations.  All three show as playing, but no audio.  After the last sirius radio station was playing I pressed STOP, and stopped SC 7.3.

Alan: Your thoughts on this one? 

I think that this is a problem that triode reported and for which I offered a proposed fix but which he said was, in fact, not needed. Perhaps it is really.

Great thanks for looking into this Alan.  Any idea how long it will take for Triode or someone else to offer a fix?  If you dont think it will be in the next few nightly builds, I can probably just revert back to SC 7.2; like others who have had this issue.

No, it is unlikely to be in the nightlies in the near future because I was not really sure about the fix I came up with earlier. 

Was this fixed??  I've been stuck using 7.2.1.  Id love to take advantage of the new bug fixes since 7.2.1.

No, It is not. I guess I could look at including the possible fix in 7.4. I am not sufficiently sure of the side-effects to risk putting it into the 7.3 tree at this stage.

I have been chasing another bug with Softsqueeze playing Flac transcoded WMA streams with Linux system which are using mplayer.   Mplayer startup has a long delay between telling SoftSqueeze to play and actually sending data to Softsqueeze.  In that time Softsqueeze overwrite its expected format setting of Flac with MP3 as the expected format. So when data arrives Softsqueeze cannot play the stream as it tries to play it as MP3 wheres it is really Flac.

You can test whether this problem is happening here by making sure the WMA streams are transcoded to MP3 (i.e. disable FileTypes WMA->Flac and WMA->WAV).

Alternatively you can test with my patched Softsqueeze (although I am not 100% sure of the fix) -  http://homepage.eircom.net/~altondsl/slim/SoftSqueeze.jar

I'm currently just using a vanilla, unmodified version of Squeezecenter 7.2.1 (file types settings at installation defaults) under Windows Vista OS using Lame.exe transcoding, and mp3 streaming method=proxied for Softsqueeze 3.7

I am unclear what you want me to test.  Could you please verify that Sirius Radio is using a different audio format than pandora and slacker; and, that's the reason why it stopped working after SC 7.2.1?  Will your softsqueeze fix help reliability in general for Internet radio stations using Softsqueeze?

I would strongly prefer to only upgrade to the latest SC beta + your jar if you can verify that sirius radio did in fact break in SC 7.3 and now works correctly using your softsqueeze.jar (using the default installation settings).

Thanks in advance for the clarification and verification.


(In reply to comment #14)
> I have been chasing another bug with Softsqueeze playing Flac transcoded WMA
> streams with Linux system which are using mplayer.   Mplayer startup has a long
> delay between telling SoftSqueeze to play and actually sending data to
> Softsqueeze.  In that time Softsqueeze overwrite its expected format setting of
> Flac with MP3 as the expected format. So when data arrives Softsqueeze cannot
> play the stream as it tries to play it as MP3 wheres it is really Flac.
> 
> You can test whether this problem is happening here by making sure the WMA
> streams are transcoded to MP3 (i.e. disable FileTypes WMA->Flac and WMA->WAV).
> 
> Alternatively you can test with my patched Softsqueeze (although I am not 100%
> sure of the fix) -  http://homepage.eircom.net/~altondsl/slim/SoftSqueeze.jar

I can't play Pandora, Slacker or Sirius as I am not in elibigle country. From your log - with Sirius your are trying to play an mms URL (i.e. WMA stream) so I see no special treatment.  

I think in 7.3 there is a change in timing of protocol messages and I think this affects Softsqueeze if there is a delay between starting the request to play and Sirius sending data to wmadec.   One of the symptoms I saw with my bug was no audio yet amount of data in input buffer exceeded the buffer threshold.   Even though your logs do not have the delay symptom, one of your logs has this sort of entry.
[09-01-21 09:54:32.0844] Slim::Player::Player::_buffering (1172) Buffering... 1048576 / 261120

To test - have a vanilla 7.3.x installation and lame installed. Test and make sure problem still exists.  Then in Settings/FileTypes disable "Windows Media ->Flac"  "Windows Media ->WAV "and ""Windows Media ->PCM".  This should only leave "Windows Media ->MP3" enabled using wmadec/lame.  After you change the FileTypes - then try playing a Sirius stream.  If Sirius now plays OK - then it would be worthwhile testing my version of SoftSqueeze.jar

Is this the same code that Alan Young wanted to put into the SC?  I think Alan might be in the United States. I've been trying to convince him to add his fix for several weeks now.

Unlikely but I don't know what Alan was proposing - do you have a reference ?

This fix is for a Softsqueeze bug which is now more prevalent with 7.3 and WMA decoding on Linux but I think happened occssionally with AlienBBC/RealAudio since 6.5.

I have been upgrading/downgrading between 7.3 and 7.2.1 already.  I would prefer to upgrade to 7.3 when at least one developer can reproduce a fix; as I'm not in the position to experiment on my SC machine (with several softsqueeze client dependancies).  I can understand why you can't do it because you're no in United States.  But I'm still surprised why this bug has been ignored since the introduction of 7.3. 

There are at least two other developers aware of this problem... see comment below:

  -------  Comment #9 From  Alan Young   2009-01-22 09:17:29   (-) [reply] -------

I think that this is a problem that triode reported and for which I offered a
proposed fix but which he said was, in fact, not needed. Perhaps it is really.
----------------------------------------------------------------------------------



(In reply to comment #18)
> Unlikely but I don't know what Alan was proposing - do you have a reference ?
> 
> This fix is for a Softsqueeze bug which is now more prevalent with 7.3 and WMA
> decoding on Linux but I think happened occssionally with AlienBBC/RealAudio
> since 6.5.

FYI, the bug I'm talking about is 100% reproducible with anyone who uses Sirius radio using SC 7.3 and using the softsqueeze distributed with that version.  Other Internet radio stations work fine with 7.3 the last time i checked.  This should be very staight forward for a developer in the United States to try and confirm.

(In reply to comment #19)
> I have been upgrading/downgrading between 7.3 and 7.2.1 already.  I would
> prefer to upgrade to 7.3 when at least one developer can reproduce a fix; as
> I'm not in the position to experiment on my SC machine (with several
> softsqueeze client dependancies).  I can understand why you can't do it because
> you're no in United States.  But I'm still surprised why this bug has been
> ignored since the introduction of 7.3. 
> 
> There are at least two other developers aware of this problem... see comment
> below:
> 
>   -------  Comment #9 From  Alan Young   2009-01-22 09:17:29   (-) [reply]
> -------
> 
> I think that this is a problem that triode reported and for which I offered a
> proposed fix but which he said was, in fact, not needed. Perhaps it is really.
> ----------------------------------------------------------------------------------
> 
> 
> 
> (In reply to comment #18)
> > Unlikely but I don't know what Alan was proposing - do you have a reference ?
> > 
> > This fix is for a Softsqueeze bug which is now more prevalent with 7.3 and WMA
> > decoding on Linux but I think happened occssionally with AlienBBC/RealAudio
> > since 6.5.

I think the bug that Triode and Alan were referring to is bug #10024 which is very similar except no Softsqueeze.

I'm still trying to find out why this bug only affects sirius radio 100% consistently and not other radio stations.  You had mentioned "I think in 7.3 there is a change in timing of protocol messages and I think this affects Softsqueeze if there is a delay between starting the request to play and Sirius sending data to wmadec."  This fix doesnt seem to be specific to the nature Sirius Radio is handled; and, more applicable/relevant if the symptom occurred in all the Internet radio stations such as bug #10024.  Can Sirius radio be "THAT" much different than other Internet radio stations to consistently behave differently?

(In reply to comment #21)
> I think the bug that Triode and Alan were referring to is bug #10024 which is
> very similar except no Softsqueeze.

The bug I am talking about can affect all ordinary WMA stations using Softsqueeze when the decoding is done using mplayer on Linux systems.  I haven't tested for the big on Windows.

Sometime a stations will start playing but more often than not, the station will not play so the problem is easily reproduced but as it is timing related it is not 100%.  Again as it is a station response time, it is more prevalent with slower stations (i.e. more likely to happen with 24k stream rather than 64k or 128k)

Brian, this sound dangerously similar to the unsolved timing/audio bug with Internet Radio Stations and Slimplayer I reported a LONG time ago: Bug 8138:  https://bugs-archive.lyrion.org/show_bug.cgi?id=8138

I spent many months trying to convince one of the developers to fix this problem.. however, they decided to "dust this problem under the carpet" since nobody was willing to figure out the problem and Richard T. didnt have the documentation necessary for the Slimplayer source code.

If you managed to provide a fix for this bug... you would have accomplished something no other developer could/would do.

I think we are talking about two different bugs.  Can you please confirm that the bug you think you fixed fixes the following symptoms:

PROBLEM:

While listening to a radio station provided by SqueezeNetwork (ie Pandora and
Slacker), if I switch to a new station to play, I will not hear any audio; or,
the audio will flipflop back and forth between the old and new channel.  

Sometimes, the only way to force the audio to be heard is to press PAUSE/PLAY
after its connected and buffered.

Sometimes, the audio wont start playing until you press PLAY 2-3 times.



(In reply to comment #23)
> The bug I am talking about can affect all ordinary WMA stations using
> Softsqueeze when the decoding is done using mplayer on Linux systems.  I
> haven't tested for the big on Windows.
> 
> Sometime a stations will start playing but more often than not, the station
> will not play so the problem is easily reproduced but as it is timing related
> it is not 100%.  Again as it is a station response time, it is more prevalent
> with slower stations (i.e. more likely to happen with 24k stream rather than
> 64k or 128k)

I don't use Softsqueeze - all I started was to track down a WMA decode problem with AlienBBC. To that end I found a few ways stations would not play with recent SC 7.3.3.  The major one was Softsqueeze bug.  I can't verify any of your symptoms but except for the channel flipping - the bug could cause no audio and possibly the need for mulitple Pause/Play (i.e. results in restart station as stations would never started properly).

This is a softsqueeze only bug - squeezeslave and squeezeplay both use the same mplayer decode but stations play OK  Have you tested Sirius with squeezeslave or squeezeplay ?

I have not, but I'm willing to bet youre right.  Since this is specific to the client.  It doesnt happen with any hardware playback devices.

I know that your fix will fix at least one problem with Slimplayer.  However, I am not so confident that it will fix Sirius Radio not playing back at all; when all other Radio stations playback.  Your fix sounds like it makes audio playback stable based on timing issues.

It would be great to have one developer in United States seriously take a look at (and confirm) why sirius radio ONLY broke for slimplayer in version 7.3

Squeezeplay works on one of my machines just fine; but, I use proprietary software that requires softsqueeze.jar, so switching to squeezeplay is not an option for me.

(In reply to comment #25)
> I don't use Softsqueeze - all I started was to track down a WMA decode problem
> with AlienBBC. To that end I found a few ways stations would not play with
> recent SC 7.3.3.  The major one was Softsqueeze bug.  I can't verify any of
> your symptoms but except for the channel flipping - the bug could cause no
> audio and possibly the need for mulitple Pause/Play (i.e. results in restart
> station as stations would never started properly).
> 
> This is a softsqueeze only bug - squeezeslave and squeezeplay both use the same
> mplayer decode but stations play OK  Have you tested Sirius with squeezeslave
> or squeezeplay ?

FYI, I replaced softsqueeze.jar with the version provided with SC 7.2.1, it seems to work better than the one it replaced.  Radio stations now start pretty much every time.. I dont have that problem with the inconsistent problem with no audio after pushing play. 

I'm a bit hesitant to upgrade my entire SC to the latest version until I get confirmation from a developer that the problem with Sirius Radio has been resolved. 

Thanks so much for your help.  Hopefully we'll get another developer to confirm that you have fixed what was broken in SC 7.3.... no sirius radio via slimplayer.

PS:  I meant in my previous comment, I am now using the jar file you created instead of the one that came with 7.2.1.. it seems to be working great!  Unfortunately, I wont know if sirius radio is also fixed with this until another developer in United States tries it.

SoftSqueeze is now Community supported and as such I think there won't be much direct developer help. I've put a post on the Developers forum about this Softsqueeze bug and requesting somebody to test Sirius.  If there is no response to that post - then I think a post in General Discussion might get some volunteers.

When you say 'slimplayer', do you mean 'SoftSqueeze', or something else?

I think "slimplayer" is a typo.  The bug seems to be that 
* Sirius will not play on Softsqueeze when using 7.3.x.  
* Sirius will play on Softsqueeze using SC 7.2.1.  
* Sirius will play on hardware players using SC 7.3.x
* No info on whether Sirius will play using squeezesalve or Squeezeplay.

Forgot a bit of info.

The bug of Sirius/Softsqueeze and SC 7.3 is with default FileType settings (i.e. WMA->Flac).  I'd like somebody to test with WMA->MP3 settings.

Are we talking about using Alien/mplayer, or on Windows using the default-supplied (bit only for Windows) wmadec?

For Alien, I just made it work by changing the Alien custom-convert.conf as follows:

wma flc * *
        # F:{PATH=%f}R:{PATH=%F}T:{START=-ss %s}U:{DURATION=-endpos %w}
        [mplayer.sh] -really-quiet -vc null -vo null $START$ $DURATION$ -cache 128 -af volume=0 -ao pcm:file=/dev/fd/3 $PATH$ | [flac] -cs --totally-silent --compression-level-0 -

This is so that %F is used for the remote-URL substitution, which should be the real stream URL. Otherwise (implicitly) %f is used, which in this case is something like "sirius://coffeehouse", which unsurprisingly does not work.

Actually, testing this with SqueezePlay, it does not work all that well. Sounding weird and worbly. I get the same bad sound when I use an SBR, but forcing it to use mplayer/flac instead of native WMA decoding.

I do not have a Windows system, so cannot test with wmadec. This is the scenario that was being discussed in bug 10024, I think.

Actually, just testing a Sirius stream with plain mplayer on the desktop, it exhibits the weird and rather unpleasant sound. Maybe my mplayer needs a better codec.

As a result of debugging WMA->Flac using mplayer on Linux nbased SC - I have found a bug in SoftSqueeze.

If a STRM-t message is sent by SC between the STRM-s and CONT message when starting the Flac decode WMA stream- Softsqueeze will not be able to play the stream.  This happens with mplayer because of the delay filling its 128k cache esp with slow streams.  It could also happen with wmadec if the responding stream is "slow" - since I can't access Sirius I do not know if that is the case but it seemed possible and if so an opportunity to close a bug report.

Great, It seems like you guys made some progress.  Can we please find a developer that can test/fix Sirius Radio playback with the current Windows Squeeze Center and the respective Softsqueeze distributed with it?

(In reply to comment #35)
> As a result of debugging WMA->Flac using mplayer on Linux nbased SC - I have
> found a bug in SoftSqueeze.
> 
> If a STRM-t message is sent by SC between the STRM-s and CONT message when
> starting the Flac decode WMA stream- Softsqueeze will not be able to play the
> stream.  This happens with mplayer because of the delay filling its 128k cache
> esp with slow streams.  It could also happen with wmadec if the responding
> stream is "slow" - since I can't access Sirius I do not know if that is the
> case but it seemed possible and if so an opportunity to close a bug report.

Okay Bryan, I finally upgraded to SC 7.3.2.  I have good news and bad news.

You were right, I can confirm that disabling "Windows Media
->Flac"  "Windows Media ->WAV "and ""Windows Media ->Native" allowed me to play Sirius Radio.

When I tried your Slimplayer.jar file, I could hear sirius radio audio, but one problem I noticed right away:

During Sirius Radio playback:

In CLI, typing "status - 1"

Artist, Title, etc tags are not being updated with correct information.  

I'm curious why so many things broke in version 7.3.  7.2.x was fully functional.  I haven't tested to see if anything else is broken.  Any chance we could get this fixed too? 

FYI:  I noticed that the Jar file you sent me is smaller than the version from 7.2.1.  Did you perhaps take out any other functionality?

Thanks for all your help!

> You were right, I can confirm that disabling "Windows Media ->Flac"  "Windows
> Media ->WAV "and ""Windows Media ->Native" allowed me to play Sirius Radio.

Good - that proves it is the same bug I found.  However my fix to Softsqueeze is not 100% as it can still break.  

> When I tried your Slimplayer.jar file, I could hear sirius radio audio, 
> but one problem I noticed right away:
> During Sirius Radio playback:
> In CLI, typing "status - 1"
> Artist, Title, etc tags are not being updated with correct information.  
I think this is not related to SoftSqueeze - the CLI is supported with SC not the player.  That is a separate bug - if it happens with a hardware player, then it should get fixed.

> I'm curious why so many things broke in version 7.3.  7.2.x was fully
> functional.  I haven't tested to see if anything else is broken.  Any chance 
> we could get this fixed too? 
If it is a real bug on a supported player and can be reproduced by developers  - then there is a good chance it would be fixed but it needs to be reported as a bug in its own right.


> FYI:  I noticed that the Jar file you sent me is smaller than the version from
> 7.2.1.  Did you perhaps take out any other functionality?
It is not "signed" so you cannot download it and run it as an applet. When signed the files grow a small amount with the addition of signatures.

I dont have any hardware players.  Can you (or anyone copied via email for this bug please see if CLI is broken in the scenario described below?

During Sirius Radio playback (using any hardware player):
1) Telnet to CLI
2) Type "status - 1"

See if artist name and title of song is displayed.  If its broken, it will just show the name of the Sirius radio channel.  Correct output would be something like this:

0b%3A02%3A91%3A11%3A4a%3A96 status - 1 player_name%3ASoftSqueeze%20-%20 player_connected%3A1 player_ip%3A127.0.0.1%3A55410 power%3A1 mode%3Aplay remote%3A1 current_title%3A time%3A33 rate%3A1 mixer%20volume%3A70 playlist%20repeat%3A2 playlist%20shuffle%3A0 playlist_cur_index%3A0 playlist_timestamp%3A1236821991.57618 playlist_tracks%3A1 playlist%20index%3A0 id%3A1918 title%3AStep%20In%20The%20Arena artist%3AGang%20Starr

Thanks,
Michael

(In reply to comment #38)
> > You were right, I can confirm that disabling "Windows Media ->Flac"  "Windows
> > Media ->WAV "and ""Windows Media ->Native" allowed me to play Sirius Radio.
> 
> Good - that proves it is the same bug I found.  However my fix to Softsqueeze
> is not 100% as it can still break.  
> 
> > When I tried your Slimplayer.jar file, I could hear sirius radio audio, 
> > but one problem I noticed right away:
> > During Sirius Radio playback:
> > In CLI, typing "status - 1"
> > Artist, Title, etc tags are not being updated with correct information.  
> I think this is not related to SoftSqueeze - the CLI is supported with SC not
> the player.  That is a separate bug - if it happens with a hardware player,
> then it should get fixed.
> 
> > I'm curious why so many things broke in version 7.3.  7.2.x was fully
> > functional.  I haven't tested to see if anything else is broken.  Any chance 
> > we could get this fixed too? 
> If it is a real bug on a supported player and can be reproduced by developers 
> - then there is a good chance it would be fixed but it needs to be reported as
> a bug in its own right.
> 
> 
> > FYI:  I noticed that the Jar file you sent me is smaller than the version from
> > 7.2.1.  Did you perhaps take out any other functionality?
> It is not "signed" so you cannot download it and run it as an applet. When
> signed the files grow a small amount with the addition of signatures.

You won't get Sirius metadata unless using a hardware player and native WMA playback.

It works fine with all previous versions up until SQ 7.3.x  Which is why I asked.

(In reply to comment #40)
> You won't get Sirius metadata unless using a hardware player and native WMA
> playback.

I meant all previous versions... 7.2.1 and older with Softsqueeze all at their default file type settings.  Something broke, causing it not to work with softsqueeze.. so I wanted to make sure if it doesnt work with the hardware players too, to fix it.

(In reply to comment #41)
> It works fine with all previous versions up until SQ 7.3.x  Which is why I
> asked.
> 
> (In reply to comment #40)
> > You won't get Sirius metadata unless using a hardware player and native WMA
> > playback.

Well I think that I am right about that. Metadata parsing for Sirius was introduced with 7.3. I'm not sure how metadata might have been working before. Andy, can you comment?

WMA metadata is parsed by the player firmware, so Softsqueeze or any transcoders do not support this.

Where is the metadata coming from when playing back sirius radio (shown in below screenshot?  This works with 7.2.1 and older.  It doesnt work with 7.3.x.  I use this command regularly, that's how I know.  I just wanted 7.3.x CLI provide information the same way as all previous versions.  For some reason it stopped working for Sirius Radio.  It works for all other radio stations in 7.3.x.

http://s67.photobucket.com/albums/h283/mkanet/?action=view&current=Screenshot-0603.jpg


(In reply to comment #44)
> WMA metadata is parsed by the player firmware, so Softsqueeze or any
> transcoders do not support this.

The way we get Sirius metadata was changed, and Softsqueeze is not supported.

Oh okay, just to be clear, this functionality was broken in 7.3.x, but since Softsqueeze isn't supported, no effort will be made to make it work again?  (In respect to what I mentioned above in the screenshot)?

(In reply to comment #46)
> The way we get Sirius metadata was changed, and Softsqueeze is not supported.

That's right.

Bug 7711 Comment #5  has a patch that may address this issue.

Thanks Richard, there several people who have been hoping for a fix for the problem mentioned in bug 7711.  I'm not sure you guys are aware of this, but there are multiple/duplicate bug reports that report this specific issue; unfortunately, none of the bug reports were addressed with a working software patch/fix; even when Softsqueeze was still supported (kept getting pushed off to future target milestones).  There are probably more, but here are the bugs I know of that report the same problem: (Bug 8138, Bug 7725, Bug 7711)

(In reply to comment #49)
> Bug 7711 Comment #5  has a patch that may address this issue.

The patch will fix the playing of transcoded WMA streams.  It will not fix the metadata issues as SoftSqueeze does not decode the WMA stream and so Softsqueeze does not "see" the WMA metadata.

Bryan:  PS:  Would it be okay with you for freeware software apps that need softsqueeze to work correctly, to include & apply this patch automatically?

Michael: thank you for taking the time to help us support Softsqueeze.  Would you mind marking any other bugs that may be fixed by Bug 7711 as 'Depends On' 

If you are unable to do that, you can email me the bug numbers and I'll take care of it.

James: If I see any more bugs that may be fixed by Bug 7711, I will be sure to mark it as 'Depends On'

Hopefully, it's clear by all the bugs reports on bugzilla (and multiple issues reported on the forums) that there's a definite need/demand for this bug fix from the public.  It would be good for a developer to PLEASE compile a softsqueeze 3.8 that's publicly available.  If that wont happen anytime soon, to allow this fix to be distributed freely by people or developers from other freeware software products.

(In reply to comment #53)
> Michael: thank you for taking the time to help us support Softsqueeze.  Would
> you mind marking any other bugs that may be fixed by Bug 7711 as 'Depends On' 
> 
> If you are unable to do that, you can email me the bug numbers and I'll take
> care of it.

Both 3.8 and 3.9beta have been publicly available for a good while.

3.8 has been available on sourceforge.net since Jan I think.
A further update 3.9 has also been available for a few weeks for betas testing as there were more significant changes. See http://forums.slimdevices.com/showthread.php?t=62060

James,

I think Softsqueeze 3.9 fixes the following
 10838, 10758, 8515, 8138, 7725, 7711, 7297 and possibly 3187

Confirmation is needed from other users.

Thanks so much!  I didn't realize I could find it in the plugins section.  I'll let others know too.

(In reply to comment #56)
> James,
> 
> I think Softsqueeze 3.9 fixes the following
>  10838, 10758, 8515, 8138, 7725, 7711, 7297 and possibly 3187
> 
> Confirmation is needed from other users.

(In reply to comment #56)
> James,
> 
> I think Softsqueeze 3.9 fixes the following
>  10838, 10758, 8515, 8138, 7725, 7711, 7297 and possibly 3187
> 
> Confirmation is needed from other users.

Thanks, I'll like these bugs, add comments on where to find the new beta(s) and request feedback from the reporters.

Great work BTW Bryan

Bryan, FYI, Softsqueeze 3.9 doesnt include the Sirius Radio fix.  At least, I can't get it to work.  It exhibits the same symptom that's described in Bug 10758.  I posted this in the forum thread as well.  I'm glad we have a very capable developer working on Softsqueeze!  

(In reply to comment #56)
> James,
> I think Softsqueeze 3.9 fixes the following
>  10838, 10758, 8515, 8138, 7725, 7711, 7297 and possibly 3187
> Confirmation is needed from other users.

3.9 includes 3.8 fix and has more fixes than 3.8.   It includes 3.8 and fixes those condition which used to break the 3.8 fix.  I don't know what is going on.

As I said before i do not have access to Sirius so you have to provide info. At least please post logs with player.source set to DEBUG and plugin.sirius set to DEBUG. 

Given Andy's comments about metadata - I am not sure that on 3.7 Sirius will work with Softsqueeze as there may be other code that assumes Sirius  is is being played on a hardware player. 

Is Sirius supposed to work with an SB1 on 7.3 ?

I will test it more thoroughly when I get home today.  I was in a rush this morning and there's a good chance I didnt update Softsqueeze correctly (maybe still old version).  I think I might have also incorrectly disabled the wrong file types (to see if that's the bug I think it is).  If I still have a problem after doing everything correctly, I will submit debug information and any other information that might help you.  I dont think that the metadata issue affects sirius radio playback. 

(In reply to comment #60)
> 3.9 includes 3.8 fix and has more fixes than 3.8.   It includes 3.8 and fixes
> those condition which used to break the 3.8 fix.  I don't know what is going
> on.
> As I said before i do not have access to Sirius so you have to provide info. At
> least please post logs with player.source set to DEBUG and plugin.sirius set to
> DEBUG. 
> Given Andy's comments about metadata - I am not sure that on 3.7 Sirius will
> work with Softsqueeze as there may be other code that assumes Sirius  is is
> being played on a hardware player. 
> Is Sirius supposed to work with an SB1 on 7.3 ?

Can you also enable network.protocol.slimproto to INFO just to check out the issue that Triode highlighted in anothe rbug report.

No, "Slimplayer" isn't a typo.  Its part of the media center software called, "SageTV". In my opinion, the nicest player/client for SC (hardware or software); nothing comes even close.  It depends on Softsqueeze/SC.  It used to grab it's artist/song title information from metadata from SC

Screenshot:
http://mka.net/slimplayer.jpg

(In reply to comment #31)
> I think "slimplayer" is a typo.  The bug seems to be that 
> * Sirius will not play on Softsqueeze when using 7.3.x.  
> * Sirius will play on Softsqueeze using SC 7.2.1.  
> * Sirius will play on hardware players using SC 7.3.x
> * No info on whether Sirius will play using squeezesalve or Squeezeplay.

Created attachment 5158 [details]
player.source=debug, plugin.sirius=debug, network.protocol.slimproto=info

server.log while trying to playback 2 sirius radio stations.

Bryan: I have good news and bad news.  

Bad news=Your Sirius Radio patch for SoftSqueeze.jar doesnt work using SC 7.3.3 (even when using the entire Softsqueeze 3.9b1 player).  Your patch did work for SC 7.3.0 though.  

Good news=I am able to playback Sirius Radio by changing file types:
WMA->FLAC=disable, WMA->WAV=disable, WMA->Windows Media=disable. 

Comment #64 Contains the debug information you asked for while trying to play 2 sirius radio stations.  Hopefully, this will help you with fine-tuning a fix for softsqueeze (So, filetype settings for WMA can be put back to their defaults).

Let me know if you need any more information.

(In reply to comment #64)
> Created an attachment (id=5158) [details]
> player.source=debug, plugin.sirius=debug, network.protocol.slimproto=info
> 
> server.log while trying to playback 2 sirius radio stations.