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

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!

very nice - 'just worked'

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.



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:



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.

Does this work with an infra red remote?

Mine ignores my SlimDevices remote and my empeg ones don't have batteries at the moment...

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

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

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

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."

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).

I ment each remote to each system works on it's system.

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.

I'm working on it (not tonight - tango)

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?

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

All my 64K files work.
Some of my LAME VBR files have problems.

Shame my whole collection I encoded with Lame at max VBR

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 )

For me it unfortunately didn't help.

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.

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.

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.

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.

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.

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

So close.

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.

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#

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

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

Sure enough the slimp3slave code that read_packet was borrowed from declares the buffer globally.