Ok, this has now been confirmed multiple times over the course of two days. The remote appears to be fine wth respect to battery, so th eproblem is th eplayer refusing to accept remote comes when this problem happens.

Unit: Riocar (mk2a) with Rio remoteRunning player software 1.03 Developer. There are 5859 songs on the player, arranged into the following playlists: Top-level-category:Artist Name:albumname:song.mp3

While viewing mode is set to Text:Now/Next, pressing "0" on the remote to toggle Shuffle will leave the remote unusable after trying to press any other button (next/prev track for instance). The same thing will happen if the view mode is pure visual, then toggle Shuffle and then pressing INFO on the remote a couple of times.

After a lengthy upload session during the night, the remote began to work again when the player reset. This has all been duplicated again this morning. So for the time being I no longer have remote functionality.

Before getting this to happen (b4 selecting a shuffle) the remote seemed to operate properly without a hint of missed key presses.

Also, the menu text for Shuffle seems backwards to me. Showing OFF when I'm turning it ON and showing ON when turning it OFF. I suppose it could be showing the current status, but it's unintuitive the way it's currently displaying. This is both from the main menu using the button controls on the face, and when using '0' on the remote.

If this has all been covered in a previous bug message, sorry - wanted to get it written down before leaving for work. :)

Bruno

There is definitely something flakey about the Rio remote. I was playing Emptris when it suddenly died. I still had the Kenwood remote in the car, so I swapped batteries. Both batteries worked in the Kenwood.

The Rio remote works now and hasn't acted weird since. I was running 1.03 at the time. Maybe this has been ironed out in 2.00-beta3.

This is an interesting bug report, as I never had a problem pressing the 0 button on the Rio remote in 1.03, or any other software release for that matter.

I have a hunch that it's a hardware problem with your Rio Remote. Applying pressure in a certain place (in your case the 0 key) causes something to become disconnected inside the remote, and makes it cease to function until you "reboot" it by removing and re-inserting the battery.

Anyone think this sounds logical?

Also, the menu text for Shuffle seems backwards to me. Showing OFF when I'm turning it ON and showing ON when turning it OFF. I suppose it could be showing the current status,

No, the shuffle menu is not showing the current status. It's showing you what the selection will do when you press it.

The reason it looks like that is so that it makes it easy to toggle shuffle from the front panel without using the remote control. This way you can turn shuffle on and off with exactly the same keystrokes every time (down right down down) and never take your eyes off the road.

This has been mentioned so many times I'm going to put it in the FAQ.

Tony, I understand why it only shows one state in the Shuffle menu. I was saying it was showing the INCORRECT state. I'll connect up the unit again in a minute ad try this.

Also, with regards to the remote. Removing and re-inserting the battery does not fix the problem. Unfortunately I am not running mlord's kernel hack to see if any other remote codes are being reecived from other devices.

I'm not ruling out a flakey battery, but it just seems too coincidental that it happens at specific times or when doing pretty specific things. The last time it died (I had it running here at work in the lab) I was actually pressing the info button. But while in shuffle mode.

I'll post an update if I figure anything out. I'll try and stop off somewhere tonight for a battery as well.

Bruno

I was saying it was showing the INCORRECT state.

It's not showing the state at all. That's what I'm trying to say, it doesn't show a state. It shows an action.

Perhaps my new FAQ entry has it worded in a better way. Try reading this and let me know if it's any clearer to you.

Tony, I'll say it... Again... I understand exactly what you're saying. But now I'll tell you why you're wrong... :)

I've mentioned ealier... I'm using 1.03, not 2.0 as you've mentioned in your FAQ. In 1.03, the menu item for Shuffle does seem to be showing the STATE. The current state, before making the selection. What you describe as the functionality for 2.0 in the FAQ, seems a lot more intuitive.

For example. If I go to the menu and it says OFF, it means it is currently OFF. Pressing down will turn it on, but will never say ON. Until you go to the menu again to check the state.

When using the remote, pressing shuffle toggles and shows you what you have just changed it to - so in essence it is backwards from what appears in the menu, for version 1.03. Has there been any type of persistent (in whatever view setting) shuffle indicator added in 2.0?

So I'll check it off as something that's FITNR. :P

Bruno

I'm using 1.03, not 2.0 as you've mentioned in your FAQ. In 1.03, the menu item for Shuffle does seem to be showing the STATE. The current state, before making the selection. What you describe as the functionality for 2.0 in the FAQ, seems a lot more intuitive.

Yup, bang-on. It works the opposite way round in 1.x than in 2.x. (There was no good way of choosing among several different shuffle modes with the 1.x-style menu.)

Peter

Sorry, I forgot you were using version 1.03.

You might want to refrain from posting any more bug reports on version 1.03, as that is no longer being updated.

When a new version comes out, it is usually expected that when people post bug reports, they are posting it for the current version. (Since the current version usually has bugfixes to the last version.)

Since 1.03 was the last "final" release, I was under the impression that reporting outstanding bugs, to make sure they're squashed in 2.0, was a good thing. Call me lazy for not going to 2.0 to verify first whether or not it had already been addressed.

It's probably from testing things down to the nth degree at work and usually being able to tell exactly where and why and what specific function is causing the problem. :)

Bruno