When playing music, after a short while, the receiver's display becomes garbled. Rebooting looks like it clears it, i.e. boot messages are ok, but when it get's back to the main screen the image is messed up again, i.e. it looks like several different screens are being displayed without prior clear screens.

I'm running tRio 0.1.4 alpha5 with ARM 1.4 under windows 98SE and Java 1.4.2_02-b03.

The music plays ok, but the screen in not readable. Any suggestions?

As a follow up and for clarification. If I reboot the rio from the web applet, the display will clear itself for a while, but if I boot from the receiver itself, the display is not cleaned up.

I got this also when I tried to run with a wireless bridge.
Setting to unicast in trio.xml helped some, but I gave up
and ran wire.
I use ethernet, and have not tried the homenet.

This does seem to be related to my running the receiver through the 10mbs hub which improved my "start up" reliability but seems to have screwed up the display.

What do I need to do to try unicast? (This might also be the answer to my question about network traffic!)

Change the send-method

<application name="player" title="Player" scope="global" class="trio.player.TRioPlayerApp"
menu-server="arm" content-server="arm"
send-method="multicast" broadcast-address="192.168.0.255" multicast-address="230.0.0.1"
multicast-ttl="1">

Just so I'm clear, all I have to do is change the send-method from "multicast" to "unicast"? Do I need to change IP addresses or anything else?

What else will this change in the behaviour of the receivers?
Does this mean that I will not be able to synchronize multiple receivers?
I'm not saying that any of this is really bad, I'm just curious as to what this setting does. Thanks!

Hmmm....for the record I'm using broadcast. Seems that multicast is too flaky for me. I just changed the send method from "multi-cast" to "broadcast" and all seems well. I've been using it that way for several weeks. (now to connect the hub)...

Where can I learn about options such as the "send method"?

I don't think the send methods are documented any where. It's a bit technical, but here's a a quick overview:

unicast: The audio data is sent directly to a single player (via UDP on the player's ip address). Disables synchronised playback.

broadcast: The audio data is sent to everyone on the sub-network (via UPD broadcast on the broadcast-address). Sync playback is possible.

multicast: The audio data is sent to everyone who is within within 1 router hop of the tRio server (multicast on the multicast-address). Sync playback is possible, but is more of a problem in wireless set ups.

Cheers
Paul

Thanks Paul, that's helpful.

Is that the only field that one would need to change? i.e. if I change from multicast to broadcast do any other fields, ip address, need to change to support that?

The only other thing you need to check is the broadcast-address setting. The default setting (192.168.1.255) assumes that your units have ip addresses in the 192.168.1.x range - if you're using 192.168.0.x then change it to 192.168.0.255

Cheers
Paul

That should work for me. Thanks. Does any of this talk of "garbled" displays mean anything to you? Am I the only one?

I would have to say you are not the only one. I just got tRio working last night with the same setup as you except I am running WinME. After playing for only 10 minutes or so the display started getting messed up. The only way to clean it up was to restart the tRio server. I will try the solutions above tonight.

Thanks all for your help.

Cool. Are you using a hub, by any chance?
In my case, I think, repeat think, that this problem started when I connected the rio to the hub. I haven't had time since the weekend to play with it, but with luck we can figure it out together.

Cheers.

This is all a bit odd. I'd expect the screen stuff to work fine unless:
a. you're running a wireless network or
b. you have the same ip address assigned to more than 1 receiver or
c. your server machine spec is quite old (p166 or the likes)


When the trio server sends screens to the receivers, it only sends what's changed (to save bandwidth). My guess is that these are either arriving out-of-order or being lost. PM me your email address and I'll send you a version that sends the full screen every time (not just what's changed) and we can see if that fixes your problem.

Cheers
Paul

I tried all the solutions above but they don't solve my display problem. Before I get into it let me lay out my home network:
- 2 rebadged Dell Rio receivers, connected via ethernet
- 1 Computer Celeron P366 (tRio 0.1.4 alpha 5, ARM 1.4, WinME, Java 1.4.2_02 (SDK version), Bell Sympatico High Speed via USB), ethernet address
static 169.254.0.1, subnet mask 255.255.0.0
- 1 old 3com 10TBase Hub

I have tried the following:
1. Replaced 10TBase Hub with 10/100TBase switch. Same problem.
2. Changed send-method to broadcast. Changed broadcast-address to 169.254.0.1. Streaming of shoutcasts stop working. The stream
was getting to the computer but not to the Rios.
3. Changed send-method back to multicast. Changed multicast-address from default 230.0.0.1 to 169.254.0.1. Rio's kept reseting after the
tRio splash screen.

Does anybody else have any ideas. I don't think this is a network issue. I would think that if the audio is flowing that the network settings
are just fine. One thing I should note though is that once the Rio does get into this state of a screwed up screen (I would be streaming
shoutcast at the time) I would press the select knob to select another shoutcast. If I scolled around a lot the rio would suddenly become
frozen. The only way to get it work again was to pull the plug. I have done this twice (once on each unit). The thing is I did not look at the tRio
output to see if anything showed up. I will try doing this again and see if I get any results. Something isn't right in Rio town. :{>)

I wonder if this is only happening on Dell's?

>a. you're running a wireless network or
I am, but the receiver and server are hardwired through ethernet.
>b. you have the same ip address assigned to more than 1 receiver or
Only one receiver currently connected.
>c. your server machine spec is quite old (p166 or the likes)
Server is a PII-400, it's only job in life is to serve the receiver.

I'll PM you with my email address later, I'm at work right now. I'm also doing some major re-wiring of my network so may not be able test right away. (BTW the problem started before I started re-wiring )

Also this is a re-badged DELL, FWIW.

Hi Paul,

I hooked things up again last night and had the same display problem. Definately seems to be related to being connected to a 10mb hub. I changed the send method to broadcast, which had no effect.

I've PMed my email address if you want to send me the updated version of the SW.

Cheers,

Jim.

Hi Paul.

I think I've figured out what's wrong. Long story short.
I was running alpha5 with java 1.4.2_02, which I belive is a beta. Very unstable with tRio. I have reverted to 1.4.2_01 and my display problems have gone and the overall stability, so far, seem good.

I never did try the patch you sent me as I seem to be good with the "stock" alpha5.

Cheers,

Jim.

I tried Paul fixes but it did really help. I was having all sorts of problems. Display, skipping, syncing issues between receivers. I'll try with java 1.4.2_01 tonight.

Please let us know how it works out. Good luck!

My god it works. Using java 1.4.2_01 made everything work. I left the Rio with the clock displayed overnight and the display was fine this morning. Before the display would just be messed up even with just the clock running. Just one note, make sure everyone deletes all there receivers in ARM 1.4. I had issues until I did that. Good find riocanada.

I'm glad it helped, musicnut.
I'm always happy to give back when I can. My enjoyment of my receiver is much better thanks to the efforts of members of this board!