PDA

View Full Version : Can SqueezeBox send Wake-on-LAN packets?



Brendan Donohoe
2004-02-01, 11:43
Perhaps this is a question for the developers list, but I'm not a
developer, so I'm asking here: is it possible to convince the
SqueezeBox to send a Wake-on-LAN packet in response to an remote
control button press?

What's that? A server should be set to never sleep? Sure, I know
that, but I have a situation where the server has to sleep and needs a
way to be told to wake up.

Any ideas? I have perl scripts and such that will send such a packet,
but of course those require a woken computer to execute them.

Brendan

Steve Baumgarten
2004-02-01, 13:07
I was browsing through my songs the other day and found that a number of
them seemed to be missing -- turns out that they were there all right, in
the newly rescanned database and everything, but with bizarre tags.
Typically what happens is the Artist and/or Title tag is read as a two or
three character sequence that begins with what looks like a "y" with an
umlaut over it.

I wrote a quickie wrapper perl script around MP3::Info (pulled down the
latest version from CPAN), and here are the results for one of my MP3
files for the call get_mp3tag() with the nasty characters represented as
octal values:

$VAR1 = {
"YEAR" => "",
"ARTIST" => "Sylvester",
"COMMENT" => "\377\376",
"TITLE" => "\377\376D",
"ALBUM" => "",
"GENRE" => "Disco",
"TAGVERSION" => "ID3v1 / ID3v2.3.0",
"TRACKNUM" => ""
};

This is what MP3::Info returns for a title that in every MP3 player (not
to mention a number of MP3 tagging utilities) I can find shows as "Do You
Wanna Funk". In other words, it's *only* MP3::Info that's misreading the
tag.

What I've found is that the "problem" lies somewhere in the ID3v2.3 tag
and one way to fix these "problem" files is to use a utility that
completely strips out that tag and then rewrites it from scratch. But it
seems to me that if every single MP3 player and utility is able to read
and display the ID3v2.3 tag from this file -- but MP3::Info for some
reason can't -- then the real problem is with MP3::Info.

Unfortunately I don't know enough about the ID3 spec to know where
MP3::Info is going wrong. (On the other hand, I can say that it's
definitely an MP3::Info problem and not a SlimServer problem since I was
able to verify the behavior of the module via my wrapper script, outside
of the SlimServer environment.)

If anyone wants a look at the file (one example among many I have, it
seems), I uploaded it to my website:

http:://www.twocute.org/sylvester_do_you_wanna_funk.mp3

I'm not looking forward to having to "repair" dozens and dozens of MP3
files all so that MP3::Info (and by extension, the SlimServer) can read
their tags correctly -- so hopefully someone who knows more about how this
module works will be able to figure out where it's going wrong and supply
a patch.

SBB

kdf
2004-02-01, 13:18
Quoting Steve Baumgarten <sbb (AT) panix (DOT) com>:

> I was browsing through my songs the other day and found that a number of
> them seemed to be missing -- turns out that they were there all right, in
> the newly rescanned database and everything, but with bizarre tags.
> Typically what happens is the Artist and/or Title tag is read as a two or
> three character sequence that begins with what looks like a "y" with an
> umlaut over it.

unfortunately, this is the result of tags that are in unicode. SlimServer
doesn't seem to support unicode yet, and its not a simple fix to do so. I'm
afraid you are probably facing the task of retagging. you are not alone, as I
too, did much th esame thing for several (not hundreds) of files. If you use a
bulk tagger like Tag & Rename, or easytag, Musicbrainz, etc, its not as horrific
as it may seem at first.

Of course, if anyone wants to take on unicode, the patch, I'm sure, would be
greatly appreciated.

cheers,
kdf

Steve Baumgarten
2004-02-01, 14:51
> unfortunately, this is the result of tags that are in unicode.

Wow, you're right. That's exactly what it is.

> SlimServer doesn't seem to support unicode yet, and its not a simple fix
> to do so.

No doubt, at least in the sense of having all valid Unicode and
non-Unicode strings handled correctly in all contexts.

However, the current behavior isn't great; nor is the "solution" of
retagging dozens or hundreds of files. And nor is just leaving things be,
as anyone who has MP3 files with Unicode-encoded ID3 tags will have
problems browsing, searching, etc., even if those tags contain only valid
latin1 (i.e., ISO-8859-1) characters.

So here's a proposed patch / quick fix; in any event, something to consider.

Given that:

o UTF8 and latin1 are the same for all latin1 characters

o Nearly all tags in existence, however encoded, use nothing outside
of the latin1 character set

Why not do the following:

use MP3::Info qw/ :all /; # needed to import use_mp3_utf8()
use_mp3_utf8( 1 );

That sets the $UNICODE flag in MP3::Info which causes it to convert
everything to UTF8. But since what's being converted is almost certainly
nothing that can't also be represented in latin1, it's not a problem --
and the result is that regardless of whether the tag is in Unicode or not,
you get back readable, latin1 results that can be used just as always by
the rest of the perl code.

I tried this myself using the "broken", Unicode version of the track as
well as on a "fixed" version with completely rewritten, non-Unicode
ID3v2.3 tags. With the call to use_mp3_utf8( 1 ), the code returns the
correct title from both versions of the file. But without the call, the
code only returns the correct title only for the "fixed", non-Unicode
verison; for the "broken" (Unicode) version, it returns the non-decoded,
munged up UTF8 representation that I've been seeing in my "Browse Artists"
list.

So does anyone see a problem with this hack? Or more to the point, can
anyone point to a file they have where such a hack would produce worse
results than the current method?

Otherwise, I think it might be an easy way to work around the problem. I
can't be the only person to have a ton of MP3 files with Unicode-encoded
ID3 tags -- all of which fail to display in any reasonable way in the
SlimServer, even if they look just fine when played via an MP3 player.

(And now that I check the source from the latest nightly build, I see this
call in Info.pm at around line 250, but commented out. Seems like someone
tried this hack and then backed away from it -- anyone know why?)

SBB

kdf
2004-02-01, 15:08
Quoting Steve Baumgarten <sbb (AT) panix (DOT) com>:
> (And now that I check the source from the latest nightly build, I see this
> call in Info.pm at around line 250, but commented out. Seems like someone
> tried this hack and then backed away from it -- anyone know why?)

IIRC, this is a case of not working for all platforms. There are a few
different revisions of Perl commonly in use now. The foundation of slimserver's
design is that of being cross-platform compatible. Some versions just dont like
unicode, and so its not supported, currently.

-kdf

Roy M. Silvernail
2004-02-01, 16:34
On Sun, 2004-02-01 at 17:08, kdf wrote:
> Quoting Steve Baumgarten <sbb (AT) panix (DOT) com>:
> > (And now that I check the source from the latest nightly build, I see this
> > call in Info.pm at around line 250, but commented out. Seems like someone
> > tried this hack and then backed away from it -- anyone know why?)
>
> IIRC, this is a case of not working for all platforms.

Concur. In fact, I threw a little wrapper around MP3::Info today to
duplicate Steve's experiment. Then I threw in the utf8 activation and
got the same bad results.
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
Never Forget: It's Only 1's and 0's!
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

Steven Spies
2004-02-01, 17:48
I would love to see this work on the SLIMP3 too. Is it possible? Has it
already been done? Thanks, Steven

On Feb 1, 2004, at 10:43 AM, Brendan Donohoe wrote:

> Perhaps this is a question for the developers list, but I'm not a
> developer, so I'm asking here: is it possible to convince the
> SqueezeBox to send a Wake-on-LAN packet in response to an remote
> control button press?
>
> What's that? A server should be set to never sleep? Sure, I know
> that, but I have a situation where the server has to sleep and needs a
> way to be told to wake up.
>
> Any ideas? I have perl scripts and such that will send such a packet,
> but of course those require a woken computer to execute them.
>
> Brendan
>
>

Steve Baumgarten
2004-02-01, 20:37
>> IIRC, this is a case of not working for all platforms.
>
> Concur. In fact, I threw a little wrapper around MP3::Info today to
> duplicate Steve's experiment. Then I threw in the utf8 activation and
> got the same bad results.

So in other words this is something that works on Windows but not other
platforms? That seems very unlikely -- this is perl, after all.

Or is it something that works on perl 5.8 but not with an earlier version
of perl? I ran both my test script and the latest nightly build of the
SlimServer on my Windows XP laptop with ActiveState Perl 5.8, and I got
good results in both cases. I don't have an earlier version to test with,
but it's hard for me to believe that this would fail under, say, perl 5.6.
I admit, though, that it's possible.

So could you provide more details on the platform you tested on, where you
got those bad results? What version of Perl? What platform?

One other thing: there's code in MP3::Info such that even if you turn on
the Unicode flag, if Unicode::String isn't available the flag is simply
ignored:

my $unicode_module = eval { require Unicode::String };
my $UNICODE = 0;

sub use_mp3_utf8 {
my($val) = @_;
if ($val == 1) {
$UNICODE = 1 if $unicode_module;
} elsif ($val == 0) {
$UNICODE = 0;
}
return $UNICODE;
}

Note how $unicode_module is set and checked. Could this perhaps explain
what you saw? (In other words, are you sure Unicode::String is available
to be loaded for the version of perl you're running? If it's not in your
local lib directory, you'd have to stick a version in the SlimServer's
CPAN directory to make it locally available to slimserver.pl.) In my case
I can see it's in C:\Perl\site\lib\Unicode\String.pm, which is why my test
script was able to work and also why it was available for slimserver.pl.)

An easy way to check: simply check the return value from the call to
use_mp3_utf8(); if it's not 1, then the $UNICODE flag hasn't really been
enabled, and it means Unicode::String isn't findable in any path in @INC.

SBB

Roy M. Silvernail
2004-02-01, 21:27
On Sun, 2004-02-01 at 22:37, Steve Baumgarten wrote:

> So could you provide more details on the platform you tested on, where you
> got those bad results? What version of Perl? What platform?

Gentoo Linux 1.4, last 'emerge -u world' was last week, perl 5.8.3
and... wait for it!... no Unicode::String.

su -c 'perl -MCPAN -e "install Unicode::String"'

And now it works fine and the title shows up readable.

> One other thing: there's code in MP3::Info such that even if you turn on
> the Unicode flag, if Unicode::String isn't available the flag is simply
> ignored:

I'd call that a bug in MP3::Info. The POD page says use_mp3_utf8()
depends on Unicode::String being available and I assumed (yeah, I know
that old saying...) it would barf if Unicode::String were absent.
Either the POD docs should be explicit about the behavior or the module
should add Unicode::String as a dependency.

So... I patched Slim::Music::Info to import all of MP3::Info and pulled
the comments off of the lines that turn utf8 on. After deleting my tag
database and flushing the HTML cache, your Sylvester file shows up just
fine.

(aside: but now the server barfs when trying to scan wav files. I don't
know how that may be related, but the only wavs I had were for testing,
so I just deleted them. I can deal with that later.)

Patch attached, in case someone else wants to try this out.
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
Never Forget: It's Only 1's and 0's!
SpamAssassin->procmail->/dev/null->bliss
http://www.rant-central.com

Steve Baumgarten
2004-02-02, 08:11
> I'd call that a bug in MP3::Info. The POD page says use_mp3_utf8()
> depends on Unicode::String being available and I assumed (yeah, I know
> that old saying...) it would barf if Unicode::String were absent.
> Either the POD docs should be explicit about the behavior or the module
> should add Unicode::String as a dependency.

It kind of threw me, too, until I looked closely at the code. My guess is
that Unicode::String should be required by MP3::Info outright since
otherwise it just botches a fair number of ID3 tags, which then leads to
those files getting "lost" in the SlimServer database.

(Unicode::String is a simple package to install, anyway, just two .pm files.)

> So... I patched Slim::Music::Info to import all of MP3::Info and pulled
> the comments off of the lines that turn utf8 on. After deleting my tag
> database and flushing the HTML cache, your Sylvester file shows up just
> fine.

Excellent! That's exactly what I saw, too.

> (aside: but now the server barfs when trying to scan wav files. I don't
> know how that may be related, but the only wavs I had were for testing,
> so I just deleted them. I can deal with that later.)

That seems like it would be unrelated, as MP3::Info shouldn't be going
anywhere near WAV files. WAV files have their own module.

> Patch attached, in case someone else wants to try this out.

The patch looks good, but it will still rely on the Unicode::String
package being distributed in the CPAN directory along with other
third-party modules that the SlimServer relies on. Otherwise, if it's not
present and available to be loaded from somewhere in @INC, MP3::Info will
continue to silently ignore the request to use Unicode decoding and
continue to botch a lot of tags.

(One thing I haven't tried yet: letting this patch loose on my entire
music collection, just to see if it causes any problems with tags that
were otherwise being read correctly. I don't think it will, but I still
want to test it.)

Any of the Slimdevices developers want to comment? Do you think it's
worth making this tiny patch official?

SBB

Roy M. Silvernail
2004-02-02, 09:27
Steve Baumgarten said:

>> Patch attached, in case someone else wants to try this out.
>
> The patch looks good, but it will still rely on the Unicode::String
> package being distributed in the CPAN directory along with other
> third-party modules that the SlimServer relies on. Otherwise, if it's not
> present and available to be loaded from somewhere in @INC, MP3::Info will
> continue to silently ignore the request to use Unicode decoding and
> continue to botch a lot of tags.

Since Unicode::String is pure perl, I don't see a problem with adding it
to the CPAN directory.

> (One thing I haven't tried yet: letting this patch loose on my entire
> music collection, just to see if it causes any problems with tags that
> were otherwise being read correctly. I don't think it will, but I still
> want to test it.)

It didn't show up any problems on my box. I don't believe I have any
other Unicode tags, and nothing appeared broken.
--
Roy M. Silvernail is roy (AT) rant-central (DOT) com, and you're not
http://www.rant-central.com is the new scytale
Never Forget: It's Only 1's and 0's!
SpamAssassin->procmail->/dev/null->bliss

Dan Sully
2004-02-02, 09:53
* Roy M. Silvernail <roy (AT) rant-central (DOT) com> shaped the electrons to say...

> > The patch looks good, but it will still rely on the Unicode::String
> > package being distributed in the CPAN directory along with other
> > third-party modules that the SlimServer relies on. Otherwise, if it's not
> > present and available to be loaded from somewhere in @INC, MP3::Info will
> > continue to silently ignore the request to use Unicode decoding and
> > continue to botch a lot of tags.
>
> Since Unicode::String is pure perl, I don't see a problem with adding it
> to the CPAN directory.

Unicode::String is not pure perl. I looked into this a while back as well.

bootstrap Unicode::String $VERSION;

Indicates that it's using Dynaloader to pull in a shared library String.(so|dll|sl|dl)

-D
--
dd if=/dev/sarcasm of=/dev/clue

Steve Baumgarten
2004-02-02, 10:13
> Unicode::String is not pure perl. I looked into this a while back as well.
>
> bootstrap Unicode::String $VERSION;
>
> Indicates that it's using Dynaloader to pull in a shared library
> String.(so|dll|sl|dl)

Crap, you're right; that's what I get for investigating so close to my
bedtime last night...

Maybe I'll look at the code a bit and see if I can come up with a pure
perl solution -- it doesn't have to be totally generalized, after all, it
just has to do the quick and dirty Unicode -> latin1 conversion required
by MP3::Info.

SBB

Dan Sully
2004-02-02, 10:18
* Steve Baumgarten <sbb (AT) panix (DOT) com> shaped the electrons to say...

> Crap, you're right; that's what I get for investigating so close to my
> bedtime last night...
>
> Maybe I'll look at the code a bit and see if I can come up with a pure
> perl solution -- it doesn't have to be totally generalized, after all, it
> just has to do the quick and dirty Unicode -> latin1 conversion required
> by MP3::Info.

The problem is - how do you know what is Unicode and what isn't?

utf8 != utf7 != utf16 != shift-jis, etc.

It's hard to convert to something if you don't know what you are converting from.

The alternate way is to punt and just turn any high-bit chars > 128
(or 255 for ascii) into ?'s or something similar.

-D
--
<faisal> my life is collapsing to what will soon be NEGATIVE INTEGER degrees of separation.

dean
2004-02-02, 11:50
Actually, the latest nightly builds do have support (from a recent
patch by Olaf Lenzmann) that will interpret unicode tags and convert
the characters that map directly to Latin-1 characters. Other
characters will be replaced by '?'.

If that's not working, please send me one of the songs files in
question and I'll figure out what's going on.

-dean

On Feb 1, 2004, at 12:18 PM, kdf wrote:

> Quoting Steve Baumgarten <sbb (AT) panix (DOT) com>:
>
>> I was browsing through my songs the other day and found that a number
>> of
>> them seemed to be missing -- turns out that they were there all
>> right, in
>> the newly rescanned database and everything, but with bizarre tags.
>> Typically what happens is the Artist and/or Title tag is read as a
>> two or
>> three character sequence that begins with what looks like a "y" with
>> an
>> umlaut over it.
>
> unfortunately, this is the result of tags that are in unicode.
> SlimServer
> doesn't seem to support unicode yet, and its not a simple fix to do
> so. I'm
> afraid you are probably facing the task of retagging. you are not
> alone, as I
> too, did much th esame thing for several (not hundreds) of files. If
> you use a
> bulk tagger like Tag & Rename, or easytag, Musicbrainz, etc, its not
> as horrific
> as it may seem at first.
>
> Of course, if anyone wants to take on unicode, the patch, I'm sure,
> would be
> greatly appreciated.
>
> cheers,
> kdf
>

Steve Baumgarten
2004-02-02, 11:56
> The problem is - how do you know what is Unicode and what isn't?

Well, there's actually some code in MP3::Info right now that checks for
encoding, at least in the ID3v2 tag. I'm not sure what the situation is
in the ID3v1 tag -- it seems there can be Unicode encoding there, but the
current MP3::Info code just assumes it's latin1. I think all that code
can be removed, as latin1 is latin1 regardless of whether it's encoded as
utf8.

> utf8 != utf7 != utf16 != shift-jis, etc.
>
> It's hard to convert to something if you don't know what you are
> converting from.
>
> The alternate way is to punt and just turn any high-bit chars > 128
> (or 255 for ascii) into ?'s or something similar.

I think punting is the way to go here. Consider that currently 100% of
the files with Unicode tags are being munged -- in other words, currently
we're punting on everything. Perhaps with a hack or two we could read 95%
of the Unicode-encoded MP3 files and just botch the remaining 5% of them
-- that would definitely be an improvement over the current situation,
even if it isn't a perfect solution.

In looking at what's available and playing around with the code a bit, I
believe we can substitute use of the Encode module (which part of CORE for
perl 5.8 and above and thus included with every standard perl 5.8
distribution) and eliminate the need for Unicode::String.

In very quick and dirty testing just now, I took this code in get_mp3tag():

if ($UNICODE) {
if ($encoding eq "\001" || $encoding eq "\002") { # UTF-16, UTF-16BE
my $u = Unicode::String::utf16($data);
$data = $u->utf8;
$data =~ s/^\xEF\xBB\xBF//; # strip BOM
}
}

and changed it to this:

if ($UNICODE) {
if ($encoding eq "\001" || $encoding eq "\002") { # UTF-16, UTF-16BE
$data = decode( "UTF-16" $data );
$data =~ s/^\xEF\xBB\xBF//; # strip BOM
}
}

and so far have had good results, but again this is in very brief testing.
I'll let it loose on my whole MP3 collection later tonight and report
back. I also think all the other code that deals with Unicode can be
eliminated, that it's only the UTF-16 that's a problem, but again, I'll
report back after more testing. If things look good for me, I'll create a
real patch and then perhaps other people can try it on their MP3
collections.

One question: even though Encode is a standard perl 5.8 module, it does
still rely on .so files -- it's not pure perl. Is that a problem? In
other words, does slimserver.pl take care to use only those modules that
are pure perl and thus 100% cross-platform (perhaps due to the way the
server is distributed), even including standard modules? If so, I'll go
back to finding a pure perl solution.

SBB

Steve Baumgarten
2004-02-02, 13:17
> Actually, the latest nightly builds do have support (from a recent
> patch by Olaf Lenzmann) that will interpret unicode tags and convert
> the characters that map directly to Latin-1 characters. Other
> characters will be replaced by '?'.

I don't see any evidence of that code -- the nightly build I downloaded
last night definitely didn't do the right thing out of the box with
Unicode-encoded ID3v2 tags.

> If that's not working, please send me one of the songs files in
> question and I'll figure out what's going on.

Happy to do so -- you can grab it here:

http:://www.twocute.org/sylvester_do_you_wanna_funk.mp3

One other thing, in browsing the latest nightly build I see that in fact
architecture-dependent files are included -- Time::HiRes being one. So in
theory Unicode::String could also be included, right, even though it's not
pure perl? Given that the existing MP3::Info code works when
Unicode::String is included and the $UNICODE flag is set, this seems to me
the easiest way to solve the problem -- just bundle it along with the
server right along with Time::HiRes.

SBB

dean
2004-02-02, 13:31
Works fine here both in the web and player user interface.

If you are using the new ID3 tag database, you might need to wipe your
ID3 cache file and rescan.

-dean

On Feb 2, 2004, at 12:17 PM, Steve Baumgarten wrote:

>> Actually, the latest nightly builds do have support (from a recent
>> patch by Olaf Lenzmann) that will interpret unicode tags and convert
>> the characters that map directly to Latin-1 characters. Other
>> characters will be replaced by '?'.
>
> I don't see any evidence of that code -- the nightly build I downloaded
> last night definitely didn't do the right thing out of the box with
> Unicode-encoded ID3v2 tags.
>
>> If that's not working, please send me one of the songs files in
>> question and I'll figure out what's going on.
>
> Happy to do so -- you can grab it here:
>
> http:://www.twocute.org/sylvester_do_you_wanna_funk.mp3
>
> One other thing, in browsing the latest nightly build I see that in
> fact
> architecture-dependent files are included -- Time::HiRes being one.
> So in
> theory Unicode::String could also be included, right, even though it's
> not
> pure perl? Given that the existing MP3::Info code works when
> Unicode::String is included and the $UNICODE flag is set, this seems
> to me
> the easiest way to solve the problem -- just bundle it along with the
> server right along with Time::HiRes.
>
> SBB
>
>

Chuck Pelto
2004-02-03, 07:20
Woke up this morning and the SLIMP3, which worked fine yesterday, is in
"Stopped" mode. And nothing I can do seems to get it to "Play".

Please advise....

Jack Coates
2004-02-03, 07:43
On Tue, 2004-02-03 at 06:20, Chuck Pelto wrote:
> Woke up this morning and the SLIMP3, which worked fine yesterday, is in
> "Stopped" mode. And nothing I can do seems to get it to "Play".
>
> Please advise....

have you tried using the web interface to start a new playlist? Sounds
to me like it's wedged on an unplayable file (corrupt, missing a
decoder).

If that doesn't do it, try restarting the service.

--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
* "A child only educated at school is an uneducated one." -- George *
* Bernard Shaw *
************************************************** ********************

Chuck Pelto
2004-02-03, 08:52
Hmmm...

....apparently more than just ONE playlist was corrupted.

Looks like a third of them got the problem. And all the ones I was
trying were in that group.

Thanks,

Chuck

On Feb 3, 2004, at 7:43 AM, Jack Coates wrote:

> On Tue, 2004-02-03 at 06:20, Chuck Pelto wrote:
>> Woke up this morning and the SLIMP3, which worked fine yesterday, is
>> in
>> "Stopped" mode. And nothing I can do seems to get it to "Play".
>>
>> Please advise....
>
> have you tried using the web interface to start a new playlist? Sounds
> to me like it's wedged on an unplayable file (corrupt, missing a
> decoder).
>
> If that doesn't do it, try restarting the service.
>
> --
> Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
> ************************************************** ********************
> * "A child only educated at school is an uneducated one." -- George *
> * Bernard Shaw *
> ************************************************** ********************
>
>

Jack Coates
2004-02-03, 10:14
On Tue, 2004-02-03 at 07:52, Chuck Pelto wrote:
> Hmmm...
>
> ...apparently more than just ONE playlist was corrupted.
>
> Looks like a third of them got the problem. And all the ones I was
> trying were in that group.
>
> Thanks,
>
> Chuck

that sounds like potential badness going on... I'd start asking
questions about that hard drive or other processes that are running.

....
--
Jack at Monkeynoodle Dot Org: It's A Scientific Venture...
************************************************** ********************
* "What difference does it make to the dead, the orphans and the *
* homeless, whether the mad destruction is wrought under the name *
* of totalitarianism or the holy name of liberty or democracy?" -- *
* Mahatma Gandhi, "Non-Violence in Peace and War" *
************************************************** ********************

Steve Baumgarten
2004-02-03, 19:02
> Works fine here both in the web and player user interface.

Turns out that this "bug" isn't a bug after all -- the version of
MP3::Info that's included with the nightly build has a patch for the
Unicode problem.

The reason the patch wasn't working for me? I happened to have had
MP3::Info installed in C:\perl\site\lib, and @INC isn't currently being
set to prefer the modules in the Slimserver's CPAN directory -- thus
slimserver.pl wasn't picking up the patched version, but rather was using
the standard version.

Dean has noted that @INC will in the future be set to look in the
Slimserver's local directories first; in the meantime I've removed the
standard version from my local perl installation and now all is well.

Sorry for leading everyone in circles on this...

SBB

Harry McQuillen
2004-02-04, 00:57
Thanks all for the helpful input in getting my squeezebox set up. It is
wired via ethernet to my Dual G4 running OS X 10.2.8. Thanks to some
input, I am running the nightly build, which has fixed some popping
problems.

One thing I've noticed that with my setup (aiff), the song authors show
up as artists on the squeezebox server. No biggie, I've deleted all authors
from the itunes library because I don't really care anway.

One more thing though, when I set up symbolic links to directories
on other volumes, though iTunes seems to read from symbolic links fine,
it doesn't put the files in the right band directory if that is through
a symbolic link. Maybe it would do it for an alias but I haven't tried it yet.
I guess could turn off "placing in iTunes library" and manually place the
..aiff's in the right directores & add, but I wish that iTunes would place
the files in the right directory.

Anyway, I know this is not a slimserver issue except for the fact that
slimserver might be able to understand aliases the way iTunes might, but
any insight from those who have travelled these paths is welcome.

-Harry

Chuck Pelto
2004-02-04, 07:09
Okay...

.....yesterday, I determined that I had corrupted lists for playing
songs.

Today, I'm confused as to why I cannot make any lists that actually
work.

From inside of the html control screen, I create playlists but they
don't play.

In iTunes I can get the music to play, so it's not a matter of the base
file being corrupted.

What's to be done?

Regards,

Chuck

Chuck Pelto
2004-02-04, 07:33
Okay...

I've found the new version of the SLIMP Server and installed it.

Now, playlists I generate seem to be playing properly.

Regards,

Chuck

On Feb 4, 2004, at 7:09 AM, Chuck Pelto wrote:

> Okay...
>
> ....yesterday, I determined that I had corrupted lists for playing
> songs.
>
> Today, I'm confused as to why I cannot make any lists that actually
> work.
>
> From inside of the html control screen, I create playlists but they
> don't play.
>
> In iTunes I can get the music to play, so it's not a matter of the
> base file being corrupted.
>
> What's to be done?
>
> Regards,
>
> Chuck
>
>