Slimserver Instructions

Posted by: ramiles

Slimserver Instructions - 01/01/2006 02:48

Would anyone please be able to share with me how I can use my Slimserver software with a Rio Receiver? Have read various posts on this board - several have posts about "directing" or "pointing" the Rio to the Slimserver (which I take to mean the port, \\PC:9000) but haven't been able to find out wether that is Rio server (T-Rio) or Rio receiver code. Appreciate any help.
Posted by: Cris

Re: Slimserver Instructions - 07/01/2006 07:54

Here Here! Good Question.

Mine is currently in one of the many storage boxes around my house, if I could figure out how to get it to work with Slimserver as you suggest I could find a use for it again.

Anyone?

Cheers

Cris.
Posted by: andy

Re: Slimserver Instructions - 07/01/2006 20:02

Well, SlimServer can provide a ShoutCast stream...

...and at least one of the alternative Receiver clients can consume a ShoutCast stream...

...so it should be possible, if not exactly optimal.

What you really need of course is a plugin for SlimServer that pretends to be a Audio Receiver Manager server. As far as I can tell such a thing does not exist.
Posted by: damage

Re: Slimserver Instructions - 13/01/2006 16:43

or you can just use medianet ( http://www.myhap.org.uk ) which can serve rios and slims.
Posted by: Bane

Re: Slimserver Instructions - 02/03/2006 15:49

I noticed that Medianet transcodes flac before playback. Does it transcode flac to wav or mp3?
Posted by: damage

Re: Slimserver Instructions - 06/03/2006 19:20

Quote:
I noticed that Medianet transcodes flac before playback. Does it transcode flac to wav or mp3?


all non-native codecs are transcoded to mp3.
Posted by: Bane

Re: Slimserver Instructions - 30/03/2006 23:28

Quote:
Quote:
I noticed that Medianet transcodes flac before playback. Does it transcode flac to wav or mp3?


all non-native codecs are transcoded to mp3.


Any chance of ever getting native flac?

Thanks

Jamy
Posted by: damage

Re: Slimserver Instructions - 31/03/2006 01:43

Quote:
Quote:
Quote:
I noticed that Medianet transcodes flac before playback. Does it transcode flac to wav or mp3?


all non-native codecs are transcoded to mp3.


Any chance of ever getting native flac?

Thanks

Jamy


doubt it. the devices would have to decode flac natively (ie in the actual hardware) and none of the supported devices do
Posted by: julf

Re: Slimserver Instructions - 25/08/2006 07:12

Quote:
What you really need of course is a plugin for SlimServer that pretends to be a Audio Receiver Manager server.


Or a Slim client on the Rios. The source for softsqueeze is available, but in java - has there been a discussion about the feasibility of java on the receiver?
Posted by: peter

Re: Slimserver Instructions - 26/08/2006 07:55

Quote:
has there been a discussion about the feasibility of java on the receiver?

In 4MB? I'd be pretty impressed.

Peter
Posted by: Roger

Re: Slimserver Instructions - 26/08/2006 09:08

Quote:
In 4MB? I'd be pretty impressed.


Well, you can get Java for Lego Mindstorms. That's only 32Kb.

I don't think there's much of an audio or networking stack in that, though
Posted by: julf

Re: Slimserver Instructions - 26/08/2006 09:18

Quote:
[Well, you can get Java for Lego Mindstorms. That's only 32Kb.


And the Dallas TINI can't have much more, being pretty much a 8051 - a decendant of the original 8080...
Posted by: dionysus

Re: Slimserver Instructions - 29/09/2006 21:31

OK - revisiting slimserver for rio threads..

Would I would LOVE to see - is this simple c program compiled for the rio receiver - possible? it's using madplay for the actual mp3 player, which should be already on the rio receiver on some of the firmware builds...

http://www.ex-parrot.com/~pdw/slimp3slave/

This has to be cakewalk for someone w/ development skills and a cross-build platform for the rio already in place!

My rio receiver's now can stream the mp3 stream out of slimserver, but the above client is much faster switching songs! (it takes ~5-10 seconds to swtich a song w/ the current method of just stremaing the music off the slimserver using the rioplay software)
-mark
Posted by: Bane

Re: Slimserver Instructions - 12/01/2007 17:34

Quote:
Quote:
Quote:
Quote:
I noticed that Medianet transcodes flac before playback. Does it transcode flac to wav or mp3?


all non-native codecs are transcoded to mp3.


Any chance of ever getting native flac?

Thanks

Jamy


doubt it. the devices would have to decode flac natively (ie in the actual hardware) and none of the supported devices do


TRio plays flac files. I'm no expert in development, but I would think that if TRio can do it, Medianet ought to be able to be made to also.
Posted by: caederus

Re: Slimserver Instructions - 12/09/2007 14:41

You might be interested in trying slimrio, which is a replacement player that speaks the SLIMP3 protocol.
Posted by: gerald_clark

Re: Slimserver Instructions - 13/09/2007 02:16

Very nice!
I think I may replace Ampache with this, if I can tune out the
infrequent audio glitches.
I really like the browse music folder option.
Posted by: julf

Re: Slimserver Instructions - 13/09/2007 06:31

Excellent! Many thanks!
Posted by: Cris

Re: Slimserver Instructions - 14/09/2007 20:50

OMG! Thank You!

Just what I have been looking for, I now have 4 more music players on my network

I am getting glitchy audio, I find it's ok if I use bitrate limiting to 160kbps. I wonder how many players I can do realtime re-sampling to at the same time ???

Cheers

Cris

PS - The solution I have is the original rio software is running on my windows box, while the slimserver runs on my clarkconnect box. Just in case anyone was wondering.
Posted by: gerald_clark

Re: Slimserver Instructions - 14/09/2007 21:08

I went to the network settings in the slimserver control panel, and doubled the UDP packet size to 2800,
Then I set display scrolling to Scroll Once and Stop.

My glitches have disappeared!
I couldn't be happier.

I am an ex user of jreceiver and Ampache.
Posted by: julf

Re: Slimserver Instructions - 15/09/2007 07:12

Regular audio glitches too, will try increasing UDP packet size.
Posted by: Cris

Re: Slimserver Instructions - 15/09/2007 08:00

I have found I need to do all 3 things to get glitch free play back.

Each of them in turn improved things, and now at 160kbps everything seems fine.

It does seem to be worse on VBR Lame encoded files, the ones I have done my self are really bad unless I bit rate limit to 160kbps. I do remember having playback problems with these files last time I used the recievers, I could be wrong ???

Cheers

Cris.
Posted by: Cris

Re: Slimserver Instructions - 15/09/2007 12:19

I am still seeing the odd blip here and there, but nothing too bad.

I can't see any other settings to change, any ideas ?

Cheers

Cris.
Posted by: julf

Re: Slimserver Instructions - 16/09/2007 07:52

Hmmpf, neither doubling UDP packet size nor reducing max bitrate to 160 seems to help, still regular (every 5-10 seconds?) glitches...
Posted by: gerald_clark

Re: Slimserver Instructions - 16/09/2007 15:43

When reducing the bitrate, the server must transcode the file.
It may not be able to keep ahead of the receiver.
If the server is busy or under powered, reducing the bitrate may cause the glitches.
Posted by: julf

Re: Slimserver Instructions - 16/09/2007 17:10

Good point, but had the glitches at full rate too.
Posted by: Cris

Re: Slimserver Instructions - 16/09/2007 18:05

Quote:
Good point, but had the glitches at full rate too.


Same here too!

It's better at lower bit rates, I get glitches towards the end of tracks maybe every 20 seconds or so.

Cheers

Cris.
Posted by: gerald_clark

Re: Slimserver Instructions - 16/09/2007 19:48

All my tracks are mp3 at 64K fixed or 128 variable.
I have nothing encoded at a higher rate to test.
Posted by: YNaught

Re: Slimserver Instructions - 13/10/2007 12:21

Quote:
Good point, but had the glitches at full rate too.

When I first tried the bitrate reduction trick, it did not work... Eventually I noticed the text above the selectbox for bitrate, saying that it could not find my lame install. After installing lame, it worked much better.
I've also noticed some glitches when it tries to scroll long filenames, am currently fooling with those settings.
I can also cause glitches by scrolling too quickly through my "artist" list (for instance). I assume it's swamping the Ethernet pipe, or the server.
An interesting point is that if you ask the RIO, it's hardy working:

nc 10.0.0.101 5000
uptime
12:01pm up 3 days, 12:01, load average: 0.00, 0.00, 0.00

...Makes me think the limitation is the poor old 10Mb ethernet connection..?
Posted by: Cris

Re: Slimserver Instructions - 13/10/2007 15:19

Quote:
...Makes me think the limitation is the poor old 10Mb ethernet connection..?


I don't think so, I have 100Mb here with 1Gb to the server and I still get the odd glitch still. I assume the Rio is 10Mb, but streaming a 160kbps mp3 should be easy over that ???

I get the feeling the problem is at the Rio end, I can do operations on the server without it effecting playback on either the Rio or my squeezebox.

But still a much better solution for me than the original software.

Cheers

Cris.
Posted by: julf

Re: Slimserver Instructions - 14/10/2007 05:51

Quote:
Makes me think the limitation is the poor old 10Mb ethernet connection..?


Probably not, as the Receiver works without glitches with other software (and same server).
Posted by: andym

Re: Slimserver Instructions - 06/11/2007 16:54

I've finally found a use for my 5 rio recievers! Slimserver is good, but AlienBBC turns it into a must have.
Posted by: julf

Re: Slimserver Instructions - 07/11/2007 08:32

Quote:
When reducing the bitrate, the server must transcode the file.
It may not be able to keep ahead of the receiver.
If the server is busy or under powered, reducing the bitrate may cause the glitches.


But the absolute regularity of the glitches would indicate a buffer problem. With 320K I get them every 5 sec (approx), with metronome regularity. Lowering bit rate makes the intervals correspondingly longer, definitely pointing to buffer issues.

On the other hand, strangely enough, I don't get the glitches on shoutcast "stations", but I *do* get them using AlienBBC to listen to BBC.

No glitches using any other client on the rio.
Posted by: andym

Re: Slimserver Instructions - 07/11/2007 15:10

Quote:
On the other hand, strangely enough, I don't get the glitches on shoutcast "stations", but I *do* get them using AlienBBC to listen to BBC.


The shoutcast stuff is MP3 and the BBC stuff is Realaudio. One of the things AlienBBC runs is an instance of mplayer to do the transcoding. I suppose there are several buffers in that chain that could underrun?
Posted by: elperepat

Re: Slimserver Instructions - 25/11/2007 18:47

Woohoo!

I just installed slimserver and slimrio on my server machine and it work s like a charm. One less reason to keep windows ;-)

I experienced some glitches too, but I transcode back to 128kpbs and lowered scroll rate. Haven't touched UDP size. I can sync 2 receivers together. I'll try more intense tests next week.

Thanks for the head-up!
Posted by: LittleBlueThing

Re: Slimserver Instructions - 17/12/2007 18:19

very nice - 'just worked' \:\)
Posted by: Raymond Day

Re: Slimserver Instructions - 04/01/2008 12:06

I spent about a hole day installing this on Ubuntu Linux server. I all ready have Slimserver running on it.

I had to stop the DHCP server on my router then my RIO got a IP after I got DHCP working on Ubuntu.

I wanted to try and make it easy for some one else. It took me all day and made a list of commands I did. I will put them in here. But others will have to change the IP's and MAC addrss's. Just edit the code before you copy and paste each line in the command prompt of you Ubuntu server. I was logged in as root when I did this.

Code:
apt-get install dhcp3-server

rv /etc/dhcp3/dhcpd.conf~ /etc/dhcp3/dhcpd.conf

rm /etc/dhcp3/dhcpd.conf

echo "authoritative;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.3 192.168.2.100;
option domain-name-servers 192.168.2.1, 192.168.2.1;
option routers 192.168.2.1;
option static-routes 192.168.2.101 192.168.2.230;
option broadcast-address 192.168.2.255;
}
host HP-Photo-smart-2610-printer {
	hardware ethernet 00:0d:9d:12:52:43;
	fixed-address 192.168.2.2;
	}
host RIO {
	hardware ethernet 00:90:00:11:47:fc;
	fixed-address 192.168.2.125;
	}" >> /etc/dhcp3/dhcpd.conf

cd /

mkdir tftpboot

cd tftpboot

mkdir 192.168.2.125

cd 192.168.2.125

wget http://empeg.org.uk/slimrio/ssdp.c

wget http://empeg.org.uk/slimrio/download/slimrio-0.7-root.tar.gz

tar -xzf slimrio-0.7-root.tar.gz

apt-get install nfs-kernel-server nfs-common

echo "tftpboot/192.168.2.125 *(ro,sync,subtree_check,insecure,no_root_squash)" >> /etc/exports

exportfs -a

echo "while true; do /bin/slimrio -s 192.168.2.109; done" >> tftpboot/192.168.2.125/sbin/init


It be nice if some one could put this in a script and have it ask for the numbers. Then all you have to do is run it and turn on your RIO.

I had to set the "reduce the audio bit rate (Player settings - Audio - Bitrate limiting). You'll need to have the LAME encoder installed first." to 128. Now it don't studder the music. I guess some of the RIO code should be made in fast assembly code so it can do faster bitrates.

I all ready had a LAME encoder installed. If you don't I guess all you have to do is this command:

Code:
apt-get install liblame0


It's super to have the RIO display look like the slimp3 player. To bad the display is not wide like the slimp3.

I am happy got this working. My RIO was just stitting there for years.
Posted by: LittleBlueThing

Re: Slimserver Instructions - 05/01/2008 20:58

Does this work with an infra red remote?

Mine ignores my SlimDevices remote and my empeg ones don't have batteries at the moment...
Posted by: Raymond Day

Re: Slimserver Instructions - 06/01/2008 13:35

Hi LittleBlueThing.

It does work with the remote. The RIO works with the RIO remote and my Slimp3 works with it's remote. Before I had this working so my RIO would play music. The remote did not work. So you have to have the RIO working before the remote will work.

I seen I have at lest one error in the code to copy and paste it's the last line. It should look like this:

echo "while true; do /bin/slimrio -s 192.168.2.109; done" >> /tftpboot/192.168.2.125/sbin/init

The 1st IP in that line is your RIO's ip and the 2nd IP is the servers IP were SlimServer is running on.

-Raymond Day

Posted by: Raymond Day

Re: Slimserver Instructions - 06/01/2008 13:52

Just seen another error on the 2nd line. It should look like this:

mv /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf~

You don't need the next line:

rm /etc/dhcp3/dhcpd.conf

Looks like some one will have to test this out to make sure it works for them. To make it easy some one should make a script out of it. That would ask you the SlimServer IP, MAC address of RIO, DHCP IP you want to do between. Thanks like that.

If any one does this please post back here that it worked or not.

-Raymond Day
Posted by: Raymond Day

Re: Slimserver Instructions - 06/01/2008 14:08

Seen yet one more error. The 1st echo don't save the /etc/dhcp3/dhcpd.conf file right. The Fixed IP's of the printer and RIO will not format right. I guess you will have to use vi to it it right. Or if some one knows how to do the echo command to save it right.

-Raymond Day
Posted by: LittleBlueThing

Re: Slimserver Instructions - 06/01/2008 16:00

I should have said, I don't have a Rio Receiver remote.

Not sure what you mean when you say "The RIO works with the RIO remote and my Slimp3 works with it's remote." smile

Do you mean the Rio Receiver, running slimrio, works with the Rio Receiver remote or it works with a squeezebox3/slimdevices remote?

Looking at the source code, slimrio includes the slimdevices IR codes - yet it doesn't work for me using the slimdevices remote.

A simple nc and then killing slimrio and running 'cat /dev/ir' doesn't show anything (so I'm guessing a HW problem).
Posted by: Raymond Day

Re: Slimserver Instructions - 06/01/2008 16:42

I ment each remote to each system works on it's system.
Posted by: wfaulk

Re: Slimserver Instructions - 19/02/2008 17:48

Originally Posted By: julf
But the absolute regularity of the glitches would indicate a buffer problem. With 320K I get them every 5 sec (approx), with metronome regularity. Lowering bit rate makes the intervals correspondingly longer, definitely pointing to buffer issues.

Has anyone tried increasing the buffer size and recompiling? The source code has a RECV_BUF_SIZE #define. I don't have a crosscompiler handy to give it a shot myself.
Posted by: LittleBlueThing

Re: Slimserver Instructions - 19/02/2008 17:53

I'm working on it (not tonight - tango)
Posted by: mardibloke

Re: Slimserver Instructions - 21/03/2008 22:18

Tried the 3 suggestions but I still get gaps in playback.

Can someone confirm they have it working fine and if so make a sample MP3 file available that they have working?

Posted by: julf

Re: Slimserver Instructions - 22/03/2008 08:00

My whole music collection works OK downscaled to 128K, but I get glitches with every song in original 256K Lame VBR.
Posted by: gerald_clark

Re: Slimserver Instructions - 22/03/2008 14:30

All my 64K files work.
Some of my LAME VBR files have problems.
Posted by: mardibloke

Re: Slimserver Instructions - 22/03/2008 20:18

Shame my whole collection I encoded with Lame at max VBR frown
Posted by: LittleBlueThing

Re: Slimserver Instructions - 22/03/2008 21:54

Try this attached slimrio
Overwrite /tftpboot/<IP>/bin/slimrio

I just did:
#define RECV_BUF_SIZE 262144

it seemed to help me - but I just played for a couple of mins without any glitches (different room, Mrs lbt calling... gotta go smile )
Posted by: julf

Re: Slimserver Instructions - 23/03/2008 08:29

For me it unfortunately didn't help.
Posted by: LittleBlueThing

Re: Slimserver Instructions - 23/03/2008 11:10

OK, I'm not using mine at the moment and I'm on holiday for a couple of weeks RSN so it won't be until I get back.

However you can just use Mark's cross-compiler suite from the hijack site. Preset the PATH to include /usr/local/arm... and change the CC in the Makefile (I'm not sure if it was preset correctly actually)

There are a couple of typedef's that declare data[] and need to be changed to *data but then it just compiles.

I also plan on allowing the IR controls to be redefined and changing the rotary knob to default to volume and seeing how to toggle the current 'settings' mode.
Posted by: gerald_clark

Re: Slimserver Instructions - 23/03/2008 19:41

Originally Posted By: LittleBlueThing
Try this attached slimrio
Overwrite /tftpboot/<IP>/bin/slimrio

I just did:
#define RECV_BUF_SIZE 262144

it seemed to help me - but I just played for a couple of mins without any glitches (different room, Mrs lbt calling... gotta go smile )


Which core, lib, and toolchain did you use?
I used:
scratchbox-core-1.0.8-i386.tar.gz
scratchbox-libs-1.0.8-i386.tar.gz
scratchbox-toolchain-arm-gcc3.4-uclibc0.9.28-1.0.4-i386.tar.gz

My binary did not run.
Posted by: LittleBlueThing

Re: Slimserver Instructions - 23/03/2008 21:26

click on hijack link above.
Scroll down to : Download Pre-Built Kernels and/or Source Code:
look for the toolchain.

Scratchbox is excellent - but quite heavy and it's a bit like using eclipse to compile helloworld.
Posted by: gerald_clark

Re: Slimserver Instructions - 23/03/2008 23:59

I was able to compile using scratchbox version 0.9.8.

I agree it is rather like pounding tacks with a sledge, but I cannot find a working link to arm-linux-toolchain.tgz

What is the hijack link?

[edit]
Never mind. I see it.
Posted by: mardibloke

Re: Slimserver Instructions - 29/04/2008 11:06

Such a shame about the stuttering playback.

Could someone thats not experiencing stuttering download and try this file, that stutters for me, and report back.

Slim Rio Test MP3 File

Thanks.
Posted by: andy

Re: Slimserver Instructions - 29/04/2008 18:11

Originally Posted By: julf
For me it unfortunately didn't help.

Nor me I'm afraid, 200k+ VBR files still glitch every few seconds.

Unless that is I set SqueezeCenter to transode everything down top 128k, but I don't really want to do that smile

So close.
Posted by: andy

Re: Slimserver Instructions - 29/04/2008 18:14

Originally Posted By: mardibloke

Could someone thats not experiencing stuttering download and try this file, that stutters for me, and report back.

As far as I can tell everyone with no stutters at all is limiting to 128k. I did some testing with that today and sure enough when I limit the bit rate to 128k it doesn't stutter anymore. Unfortunately 128k is just too low for me.

I tested with you file and it has the same issues as the VPR files I have been testing with, stutters with anything over 128k transcoding.
Posted by: andy

Re: Slimserver Instructions - 29/04/2008 18:54

Originally Posted By: LittleBlueThing

I just did:
#define RECV_BUF_SIZE 262144

Looking at the code I don't think that increasing the size of that buffer was ever going to change anything. I'm not a C coder myself, but looking at the code I think increasing that buffer size would only ever have helped deal with single large packets (which should never occur anyway, as SqueezeCenter is supposed to limit them to 1400 bytes).

As I see it read_packet() is called every time the UDP socket is polled and the following happens:

- xcalloc is called to allocate a chunk of memory to match the buffer size
- recvfrom() is called to fill the buffer from the UDP socket
- we inspect the first byte of the buffer to determine the packet's type
- if it is an MP3 data packet we send it off to receive_mpeg_data() for processing
- if it is not an MP3 packet we do other stuff with it

And that is it. Given that SqueezeCenter is already set to limit each UDP packet to 1400 bytes upping the buffer size. Unless...

...I don't know much about C/Unix socket stuff. Is expected to return the data for a single UDP packet or all the data that is waiting on the socket ?


If recvfrom() can return more than one packet then the code in read_packet() is very broken. At worst if two MP3 packet were waiting we would send an extra byte of duff data (the identifying byte on the front of the second packet) to the MP3 decoder. At worst MP3 packets would get missed if there was one queued up behind another packet type.


Also, the code never appears to free up the memory, surely it should be calling xfree() or something ?

Finally, the buffer is allocated within the read_packet function, which is called for each and every packet. Would it not be better to allocate the buffer in main() and pass the pointer through to read_packet() ?

No doubt I've got the wrong end of the stick though, probably best if I stick to C# wink

Edit: my research suggests that recvfrom() only returns one packet, so I think that side of it is a non-issue. I still think that raising the buffer size was still a non-starter though frown
Posted by: peter

Re: Slimserver Instructions - 29/04/2008 19:01

Originally Posted By: andy
Is expected to return the data for a single UDP packet or all the data that is waiting on the socket?

UDP preserves packet-boundaries, and returns at most one packet per call to read(). TCP doesn't preserve the boundaries, and returns everything that's available.

Peter
Posted by: andy

Re: Slimserver Instructions - 29/04/2008 20:55

Originally Posted By: andy

Finally, the buffer is allocated within the read_packet function, which is called for each and every packet. Would it not be better to allocate the buffer in main() and pass the pointer through to read_packet() ?

Sure enough the slimp3slave code that read_packet was borrowed from declares the buffer globally.
Posted by: andy

Re: Slimserver Instructions - 29/04/2008 21:44

I've realised that I was also talking nonsense about the buffer being allocated more than once. I looked at the code, properly this time:
Code:
	static char *recvbuf = NULL;
	struct sockaddr ina;
	struct sockaddr_in *ina_in = NULL;
	socklen_t slen = sizeof(struct sockaddr);
	int bytes_read;

	if(!recvbuf)
		recvbuf = xcalloc(1, RECV_BUF_SIZE);

This time I noticed the static declaration and the check for NULL before allocating blush

So I was wrong about most of what I said, but I still stand by my claim that increasing the buffer size would have no effect wink
Posted by: andy

Lightbulb moment ! - 30/04/2008 14:36

I've just realised that those of us with Squeezebox Controllers (I'm looking at you Rod) no longer really have a need for much of the functionality in slimrio. All that we need is a copy of the original slimp3slave player run from the init script.

I might have a play with that, I guess I would have to rip out slimp3slave's curses UI to get it to build.
Posted by: caederus

Re: Lightbulb moment ! - 02/05/2008 14:45

Sorry for my long absence from this thread. It's taken me a while to catch up and properly investigate the audio-stuttering problem. I am now sure that the trouble is that madplay/libmad can't keep up with decoding in real-time, as can be demonstrated by running it directly from the command line on a suitable file---the CPU is flat out and audio still sometimes breaks up. By comparison, the CPU is very lightly loaded by the original Rio application. Maybe they were using an exceptionally efficient mp3 decoder, but it seems possible there is something wrong with my build of libmad. Unfortunately, I've since messed up the toolchain I used (trying to swap from scratchbox to sb2 and back) and I'm currently having difficulty building anything at all.

In the meantime, I suggest those who can't live with limiting the mp3 bit-rate try this
kludged version 0.7b


I hope to have better results to report soon.
Posted by: andy

Re: Lightbulb moment ! - 02/05/2008 16:47

I am pleased to report that apart from one stutter the first time that I changed the volume that it appears to be stutter free !

Well done that man. What did you change in 0.7b ?
Posted by: elperepat

Re: Lightbulb moment ! - 02/05/2008 23:04

0.7b seems very good for me. Decoding a 320kbps VBR? mp3 (as reported by squeezecenter) without downsampling and without clitches!

uptime on the rio reports values ranging from 1.10 to 1.63 throughout the file.


Thanks! It's working great!
Posted by: Cris

Re: Lightbulb moment ! - 03/05/2008 06:06

It seems to be working great for me too smile

Brilliant, Many Thanks!

Cheers

Cris.
Posted by: andy

Click(s) when starting playing - 03/05/2008 07:12

Now that we have stuttering sorted I do have another issue to report that I hadn't bothered reporting until now.

Whenever I start playing something I get a click or thump (much like the sound when plugging/unplugging something into an amplifier that is turned on). It only happens however in when it is a user commanded action and also doesn't happen on pause/unpause:

start a new track or playlist: clicks
move to the next track in the playlist using next track: clicks
allow the next track to play after the current one finishes: no clicks
pause: no click
unpause: no click
stop (hold pause on Squeezecenter Controller): no click
restart from stop (press pause): clicks

Sometimes there is a single click, other times there are two clicks, can't work out the pattern of when there is just one click.

The clicks happen no matter how I control the player (front panel controls, Squeezebox Controller, SqueezeCenter).
Posted by: Cris

Re: Click(s) when starting playing - 03/05/2008 13:31

I'm not getting any clicking ???

I've had it on all afternoon on Random and it has been flawless the whole time on 0.7

Have you got another unit to try it with?

Cheers

Cris.
Posted by: andy

Re: Click(s) when starting playing - 03/05/2008 14:42

Originally Posted By: Cris
I'm not getting any clicking ???

I've had it on all afternoon on Random and it has been flawless the whole time on 0.7

If you had it on random all the time and didn't skip tracks then you wouldn't get any clicks (except one when you started the first track).

Originally Posted By: Cris

Have you got another unit to try it with?

I have a number, I'll just go and raid the box in the loft wink
Posted by: andy

Re: Click(s) when starting playing - 03/05/2008 18:08

I tried another unit, a Rio Receiver, which shows exactly the same symptoms. Eryl confirms that there is indeed a click, so I'm not making it up, it is extremely noticeable.

I was going to try a Dell unit as well, but I can't get those to boot, I guess I need the newer version of the ARM software.
Posted by: andy

Re: Click(s) when starting playing - 03/05/2008 19:31

My Dells definitely click as well, so that is four units all the same.
Posted by: Cris

Re: Click(s) when starting playing - 03/05/2008 19:57

Hmmm, I tried it skipping tracks etc... and can't hear a click, I even tried some tracks with a very quiet start.

What version of Slimserver are you running? I guess it will be 7, I am still on 6.something

Cheers

Cris.
Posted by: andy

Re: Click(s) when starting playing - 03/05/2008 20:21

If it was clicking you would hear it very clearly. I am on 7.01, but it was clicking on 7.0 as well.

I don't know if it happened on 6.5 as well, I was more concerned about the stuttering at that point. I'll see if I can remember to install 6.5 on a virtual machine somewhere tomorrow and see if that makes a difference.
Posted by: andy

Re: Click(s) when starting playing - 03/05/2008 21:36

Doing a quick diff of 6.5 and 7.01 there appear to be a lot of differences in the server side code for Slimp3, especially around buffering and syncing. Anyone else using 7 getting clicks ?
Posted by: elperepat

Re: Click(s) when starting playing - 03/05/2008 22:47

I'm using version 7 (and used 6.5x prior to 7) and not noticing any clicks at the beginning of tracks after a start or a skip. I have both Dell and Rio units. I use RCA outputs on all my receivers.
Posted by: Cris

Re: Click(s) when starting playing - 04/05/2008 06:31

Originally Posted By: elperepat
I use RCA outputs on all my receivers.


Me too, I don't use the integrated amp, I can dig out some old speakers to test if needed Andy.

Cheers

Cris.
Posted by: andy

Re: Click(s) when starting playing - 04/05/2008 07:37

I get clicks on both the RCAs and the speaker outputs (tested that last night as I realised I had only tested the RCAs until then).
Posted by: mardibloke

Re: Click(s) when starting playing - 04/05/2008 08:27

2 x Dell's working fine now, feel slightly cheated that I don't have the free clicks though.
Posted by: bmark

Re: Click(s) when starting playing - 10/05/2008 08:23

Fantastic! Since Paul's tRio project stalled I had been searching for an alternative to the stock software, but SlimRio's audio glitches were too annoying. Now, however, I am happy!

BTW, does anybody else miss the predictive text search abilities of the standard software? Being able to find a track by title, album or artist by pressing just a few buttons is a great feature that I miss.

Many thanks for all the hard work that's gone in to getting this to work.
Mark
Posted by: andy

Re: Click(s) when starting playing - 10/05/2008 11:42

Originally Posted By: bmark

BTW, does anybody else miss the predictive text search abilities of the standard software? Being able to find a track by title, album or artist by pressing just a few buttons is a great feature that I miss.

Try this http://www.hickinbottom.com/lazysearch
Posted by: bmark

Re: Click(s) when starting playing - 11/05/2008 05:58

Thanks Andy. I'll give it a whirl

Do you happen to know what happened to Paul N? It's a pity tRio has died, since it was developing nicely (and used the screen on the receiver properly!)

Mark
Posted by: Dearing

Re: Click(s) when starting playing - 13/05/2008 22:57

Thanks for this update! After using this version, I no longer have problems with skipping audio. As a bonus, syncing now works great! Can't say if this update would have done anything to fix syncing directly, or if it was the added load on the server having to manage the down-converting to 128 and syncing at the same time... Anyway, I've now got Sync working on 2 Receivers + SoftSqueeze + Squeezebox3. Of course, all the players don't start each track at exactly the same time, but within a few seconds all are playing correctly synced.
Posted by: andy

Re: Click(s) when starting playing - 14/05/2008 08:12

I'm clearly not having much luck with this then. As well as my problems of clicking when I start/skip a track I also have huge problems with syncing. I can't get two Rio Receivers to sync, let alone syncing with anything else.
Posted by: bmark

Re: Click(s) when starting playing - 14/05/2008 10:47

Andy,
Many thanks for the LazySearch link. It does just what I needed.

Regarding the "kludged version" of SLimRio, I tried the other fixes (downsampling, scrolling etc.) but had no luck. However the kludge has fixed my skipping problems, but I can no longer sync!
Posted by: Dearing

Re: Click(s) when starting playing - 14/05/2008 12:44

Andy and bmark,
Have you verified that syncing doesn't fix itself a few seconds into the track? Maybe even midway through the track? SC makes constant changes based on the buffer levels of all the various players.

Come to think of it, what is the memory buffer size in SlimRio? Does it report correctly to SC?

I did play around with the audio delay and start delay settings in SC, but I don't know if the audio delay values are device dependent or network dependent. One Receiver has 1000ms (over ethernet) and the other 250ms (over wifi).
Posted by: mardibloke

Re: Click(s) when starting playing - 14/05/2008 14:15

I'm back to getting "Short Packet" messages on Dell display and drop outs in playback.

Odd how it worked for a while smirk

I was certainly playing with player settings to try getting mine to sync, but cannot think why that would have messed up the playback.
Posted by: andy

Re: Click(s) when starting playing - 14/05/2008 14:46

Sometimes the Receivers start in sync and then drift off, sometimes they start out out of sync and drift off further. At no time do they stay in sync or get any closer in sync during a track frown
Posted by: andy

Re: Click(s) when starting playing - 14/05/2008 15:06

Robin appears to have simplified the buffer handling in the code that he took from the original slimp3slave. In particular his code doesn't seem to have the functionality that requests missing packets. That may explain why some of us have had what appear to be missing data issues.

It would be good to know what tweak he made to the latest 0.7 that fixed some of the buffering issues.

Given my last effort at parsing the slimrio code that should probably all be taken with a huge pinch of salt though.
Posted by: wfaulk

Re: Click(s) when starting playing - 14/05/2008 15:11

Since the ethernet on the Receiver is so flaky, maybe you could try plugging it into a different port. Maybe it's having collision issues due to bad autonegotiation.
Posted by: mardibloke

Re: Click(s) when starting playing - 14/05/2008 17:03

My two Dells are both on different switches already, one on a Cisco the other on a Dell switch. But tried other ports same results, both are dropping packets.
Posted by: wfaulk

Re: Click(s) when starting playing - 14/05/2008 17:52

If it's a managed Cisco, try forcing the interface to 10/Half and see if it helps. Also try 10/Full.
Posted by: Dearing

Re: Click(s) when starting playing - 14/05/2008 19:35

Just got in a "new" SlimP3 from eBay (SWMBO swears I just collect these things smile ). Sync works correctly between the receiver in my office and the SlimP3 only after pausing and restarting the track, and even then drifts intermittently. However, once it gets in sync, it never drifts FAR out and has played in sync for at least 2 tracks in a row. I'll try to play them in sync for a couple hours tomorrow and let you know what I find.

EDIT: Oh yeah, I did have to turn down the "Max Number of Bytes of Audio Data" to 1000 before I could get any decent sound out of the SlimP3. Maybe smaller data packets will help the syncing on SlimRio also?
Posted by: Dearing

Re: Click(s) when starting playing - 16/05/2008 00:15

Well, Syncing is still not perfect. Sometimes it will stay in sync for a few tracks in a row, sometimes I have to pause/restart and sometimes I have to adjust the Audio Delay from SC for the receiver. I may have to stick to the SlimP3 and SB3 when I want to sync, and the 2 receivers just for non-synced listening. Has anyone else had any luck syncing consistently between SlimRio and Squeezeboxen?
Posted by: Hedges

Re: Click(s) when starting playing - 10/06/2008 01:10

I'm new here. Hi.

I've been using SlimRio for a while and love it. I am now trying to move the NFS mount part to my MacBook Pro running Mac OS 10.4.11.

So far, I've gotten it to the point that I see "EMPEG Penguins Found" on the RIO (Dell) screen, but then nothing after that. So, I think the kernel is loaded, but there's a problem loading the file system over NFS.

I've tried 7.0 and 7.0b...same problem. I *did* notice that the lib directory has a group name of "Robin" which doesn't translate to a group on my Mac. Could that be the problem?

Anyone know why the boot up process could be stopping after the "Penguins Found" screen is loaded or what this means?

Thanks!
Posted by: wfaulk

Re: Click(s) when starting playing - 10/06/2008 21:40

It's possible that the SlimRio NFS client is using non-trusted port and that MacOS is denying the connection because of it. I seem to recall that happening to me with my OpenBSD server, and there's a lot of OpenBSD in MacOS.
Posted by: Hedges

Re: Click(s) when starting playing - 10/06/2008 22:50

Yup...I started researching down that path yesterday but got distracted. I'll pick that back up and see if I can find a work-around. Thanks for the tip.
Posted by: Hedges

Re: Click(s) when starting playing - 11/06/2008 02:06

I did a tcpdump and watched what the rio is doing once it puts up the "EMPEG Penguins Found" on the screen. Basically, it is in a loop whereby it requests busybox, ld-linux.so.2, libc.so.6, slimrio, etc, v4l ir, font6x16, sleep and display...and it just keeps on doing this over and over again. It gets errors on "etc" and others since they don't exist in the tar file. It just keeps looping on these requests. So, it successfully downloaded the kernel image, but is having troubles with some of the other files.

Anyone have any ideas what's wrong? As stated above, I'm running NFS on a Mac os 10.4.11.
Posted by: gerald_clark

Re: Click(s) when starting playing - 18/06/2008 20:43

Now that skipping has been eliminated, all singers seem to have a lisp.
Has anybody else noticed this?
Posted by: andy

Re: Click(s) when starting playing - 19/06/2008 07:30

Originally Posted By: gerald_clark
Now that skipping has been eliminated, all singers seem to have a lisp.
Has anybody else noticed this?

No, but it sounds like MP3 artefacts to me. Maybe you still have bitrate limiting enabled on the server and set to a low rate ?

With the latest SlimRio I returned all the other tweaks on my server back to normal.
Posted by: gerald_clark

Re: Click(s) when starting playing - 19/06/2008 21:00

It is the --downsample option to madplay.real that is causing the sibilance.
Posted by: andy

Re: Click(s) when starting playing - 19/06/2008 21:12

Ah, that would explain a couple of things. I had the feeling the quality of SlimRio's playback wasn't as good as the original Rio code, but I had convinced myself I was imagining it. So all my 44khz files are actually being downsampled to 22khz frown

It also explains how Robin managed to "fix" the stuttering problem without a working tool chain.

I'll have to do some testing and see whether I prefer 128k MP3 transcodes or a 22khz sample rate...
Posted by: presslab

Re: Click(s) when starting playing - 29/07/2008 18:16

I found the text wrapping very annoying. It is possible to modify SqueezeCenter 7 to display only 20 rows. The file is located in /usr/lib/perl5/vendor_perl/Slim/Display/Text.pm

It's a simple matter of changing all "40" to "20" and "39" to "19".

After this, the "brightness" value of "3" provides the best result.
Posted by: elperepat

Re: Slimserver Instructions - 28/10/2008 01:28

Hi!

I'm using slimrio here at home since last year. Recently, I installed slimserver and then squeezecenter under windows at my father's house. All was working fine!

But, I'm slowly converting him to linux, so the computer with squeeze is currently being transfered to ubuntu 8.04. He installed squeezecenter, dhcp server, ssdp.py and nfs server. He gets to the point of "Finding SlimServer...", but then get the message "Failed to connect to server" (or something similar).

The squeezecenter is working properly as he uses softsqueeze from another computer to play music. DHCP, SSDP and NFS seem to work correctly because he gets through "Penguins Found", then SlimRIo splash screen. He can connect to the rio using nc, so network is working for sure. He tried to specify the server's ip in /sbin/init with -s option, but it doesn't help.

Any other idea?

Thanks

Patrick
Posted by: caederus

Re: Slimserver Instructions - 28/10/2008 07:58

I'm not sure what to suggest: if you give it the -s option, slimrio doesn't do anything fancy; it just sends UDP packets to port 3483 on the specified host, so it's hard to think of anything that could be wrong on the slimrio end. Is there anything in the server's log? Does the receiver show up on the server's list of recognised players (on the status page)?

Perhaps a tcpdump of traffic between the rio and squeezecenter would shed some light on what's going on.
Posted by: elperepat

Re: Slimserver Instructions - 29/10/2008 00:15

Quote:
Does the receiver show up on the server's list of recognised players (on the status page)?

No, only the softsqueeze clients are showing, no trace of slimrio.


Now, here are a few details on to the tcpdumps:

mars.local is the server,
192.168.1.101 is the rio receiver and
192.168.1.20 is the softsqueeze client


The first file (riotcpdump.txt) is the tcpdump of the rio getting it's ip from dhcp, then getting in touch with ssdp, then getting it's filesystem from the nfs server. Then, nothing. No request on port 3483.

Second file (softsqueeze.txt) is a tcpdump from a softsqueeze connecting to the squeezecenter. Traffic on port 3483 without problem.

Finally, last file (dhcpd.conf) is dhcp configuration. I tought the problem might be in here, but I can't find anything wrong.

If we don't find a solution, we'll try to do the same on an other computer, runing ubuntu 6.06. We'll see...


One last thing. in /proc/kmsg, my father's rio stop the log at "<4>Starting kswapd v 1.5", while mine continue further. Here's my receiver's log. nc doesn't seem to be "stable" as a lot of commands just hang it, so I suspect the abrupt end of files is linked to a nc crash.

Code:
<4>Linux version 2.2.14-rmk4-mercury19 (robin@victoria) (gcc version 3.4.2 (release) (CodeSourcery ARM Q3D 2004)) #1 Mon Jul 16 17:37:22 BST 2007
<4>NetWinder Floating Point Emulator V0.94.1 (c) 1998 Corel Computer Corp.
<4>IP-Config: Parameter #0: `192.168.0.101'
<4>IP-Config: Parameter #1: `192.168.0.23'
<4>IP-Config: Parameter #2: `111'
<4>IP-Config: Parameter #4: `255.255.255.0'
<4>IP-Config: Parameter #7: `off'
<4>Calibrating delay loop... 65.33 BogoMIPS
<4>Memory: 3156k/4M available (712k code, 20k reserved, 200k data, 8k init)
<4>Dentry hash table entries: 512 (order 0, 4k)
<4>Buffer cache hash table entries: 2048 (order 1, 8k)
<4>Page cache hash table entries: 1024 (order 0, 4k)
<4>POSIX conformance testing by UNIFIX
<6>Linux NET4.0 for Linux 2.2
<6>Based upon Swansea University Computer Society NET3.039
<6>NET4: Unix domain sockets 1.0 for Linux NET4.0.
<6>NET4: Linux TCP/IP 1.0 for NET4.0
<6>IP Protocols: ICMP, UDP, TCP
<4>TCP: Hash tables configured (ehash 4096 bhash 4096)
<4>Starting kswapd v 1.5 
<4>empeg clps7212 audio driver initialized
<4>mercury display initialised.
<4>mercury infra-red support initialised.
<4>mercury rotary support initialised.
<4>mercury buttons support initialised.
<4>Probing for cs8900a
<4>eth0: cs8900 rev J found at 0x300 media RJ-45, IRQ 7 00 90 00 11 4f 1d
<4>IP-Config: Entered.
<4>eth0: using 10Base-T (RJ-45)
<4>IP-Config: Opened eth0 (able=0)
<4>IP-Config: device=eth0, local=b400a8c0, server=6500a8c0, boot=6500a8c0, gw=0100a8c0, mask=00ffffff
<4>IP-Config: host=192.168.0.180, domain=(none), path=`'
<5>Looking up port of RPC 100003/2 on 192.168.0.23
<5>Looking up port of RPC 100005/1 on 192.168.0.23
<5>VFS: Mounted root (NFS filesystem) readonly.
<4>Freeing unused kernel memory: 8k init
<5>init (1): unsupported llseek call standard
<5>init (1): unsupported llseek call standard
<5>bash (12): unsupported llseek call standard
<5>madplay (14): unsupported llseek call standard
<5>madplay (14): unsupported llseek call standard
<5>mad


Thanks for your help!

Patrick
Posted by: elperepat

Re: Slimserver Instructions - 29/10/2008 21:45

Replying to my own post:

My father found out the problem. There was a mistake in the /sbin/init file he edited.

Everything works fine now, but he must have the -s option, even though it's only a simple network with only one squeezecenter. Anyway, all is working properly. Thank you very much for your help!


Patrick
Posted by: admin69

Re: Slimserver Instructions - 25/05/2022 23:26

Originally Posted By: Raymond Day
I spent about a hole day installing this on Ubuntu Linux server. I all ready have Slimserver running on it.

I had to stop the DHCP server on my router then my RIO got a IP after I got DHCP working on Ubuntu.

I wanted to try and make it easy for some one else. It took me all day and made a list of commands I did. I will put them in here. But others will have to change the IP's and MAC addrss's. Just edit the code before you copy and paste each line in the command prompt of you Ubuntu server. I was logged in as root when I did this.

Code:
apt-get install dhcp3-server

rv /etc/dhcp3/dhcpd.conf~ /etc/dhcp3/dhcpd.conf

rm /etc/dhcp3/dhcpd.conf

echo "authoritative;
subnet 192.168.2.0 netmask 255.255.255.0 {
range 192.168.2.3 192.168.2.100;
option domain-name-servers 192.168.2.1, 192.168.2.1;
option routers 192.168.2.1;
option static-routes 192.168.2.101 192.168.2.230;
option broadcast-address 192.168.2.255;
}
host HP-Photo-smart-2610-printer {
	hardware ethernet 00:0d:9d:12:52:43;
	fixed-address 192.168.2.2;
	}
host RIO {
	hardware ethernet 00:90:00:11:47:fc;
	fixed-address 192.168.2.125;
	}" >> /etc/dhcp3/dhcpd.conf

cd /

mkdir tftpboot

cd tftpboot

mkdir 192.168.2.125

cd 192.168.2.125

wget http://empeg.org.uk/slimrio/ssdp.c

wget http://empeg.org.uk/slimrio/download/slimrio-0.7-root.tar.gz

tar -xzf slimrio-0.7-root.tar.gz

apt-get install nfs-kernel-server nfs-common

echo "tftpboot/192.168.2.125 *(ro,sync,subtree_check,insecure,no_root_squash)" >> /etc/exports

exportfs -a

echo "while true; do /bin/slimrio -s 192.168.2.109; done" >> tftpboot/192.168.2.125/sbin/init


It be nice if some one could put this in a script and have it ask for the numbers. Then all you have to do is run it and turn on your RIO.

I had to set the "reduce the audio bit rate (Player settings - Audio - Bitrate limiting). You'll need to have the LAME encoder installed first." to 128. Now it don't studder the music. I guess some of the RIO code should be made in fast assembly code so it can do faster bitrates.

I all ready had a LAME encoder installed. If you don't I guess all you have to do is this command:

Code:
apt-get install liblame0


It's super to have the RIO display look like the slimp3 player. To bad the display is not wide like the slimp3.

I am happy got this working. My RIO was just stitting there for years.



Just to update Raymond's instructions, revive an ancient thread (and to maybe provide an answer to his 2021 post over here https://ubuntuforums.org/showthread.php?t=2456483).

I have Rios running with Centos8 (soon to be Rocky) and had problems getting even to the "penguins found" screen in the boot process. Fired up Wireshark and had an error of NFS2ERR_OPNOTSUPP when trying to load zImage.

I found you must enable NFS v2 and UDP for NFS is required -- the info here is key: https://pub.nethence.com/booting/pxe.netbsd

Turns out I had to change to no_subtree_check and modify the last line of /tftpboot/RIOADDRESS/sbin/init to say "while true; do /bin/slimrio -s SLIMADDRESS; done" where the RIOADDRESS is the IP of the receiver and SLIMADDRESS is the IP of the LMS / SlimServer.

My exportfs is now:

/tftpboot/x.x.x.x *(ro,sync,no_subtree_check,insecure,no_root_squash)

Hope this can help the very few wanting to keep these going. I plan to use them in the garage, etc.