Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lOth]

Just installed Rio 500 plug-in (9.0.02) on Media Center 9.0.143. When I click on the Rio icon in the tree I receive this message: "Media Core has encountered a problem and needs to close" and then Media Center close.  I've read that other programs (e.g. sveta) have encountered problems of communication with the Rio 500 after the installation of a recent win xp security patch. Could that be it? Anyone with the same problem and hopefully a solution?

[SteveG]

*EDIT*  Before you follow the instructions below, download the new Rio 500 Plugin (v 9.0.03) and see if that works for you. I made some modifications that may handle the driver incompatibility. **


This could be related to the security patch. Regardless, it is almost certainly related to the drivers you have installed from Rio. You can try the following....

To work well with MJ you need to get the Rio drivers installed that come with the MJ Plugin. If XP has already installed the drivers that come with it, I would suggest that you remove them fully by following the directions at

http://www.sonicblue.com/support/rio/default.asp?menu=support&submenu=Legacy_Rio&item=faqs&product=Rio_500_PC#20399

Also uninstall the Rio Plugin for MJ. Make sure your Rio is disconnected and reboot.

After you reboot and BEFORE you connect your Rio, download the MJ Rio plugin. When you connect your Rio and XP asks if you want to install the default drivers, DO NOT accept the default, instead, point the installation to look in your System32 directory where it will find the drivers that we distribute with the Plug-in.

YOU MUST LOG IN ONCE AND THEN REBOOT AND LOG IN AGAIN TO GET THIS TO WORK.

[lOth]

installing 9.0.03 worked (browse the rio, format both internal and external memory, add subfolder) until I tried to actually transfer files (same Media Core error as before).

Thereafter I followed your instructions until the point when I have to look for the driver files in system32 after having installed the plug-in. No *.inf file that looks like a Rio 500 one in that folder. What's the name of the file I'm supposed to look for?

[SteveG]

You should be able to direct Windows just to look in the directory and it will find what it needs. If not, try installing the drivers you previously installed. They appeared to be working with the updated Plug-in. I did find a bug that got introduced in MC that is fixed in todays build of MC which may solve the upload crash you saw.

Steve

[lOth]

Still impossible to find the driver after installation of the plug-in. On New Hardware found --> Install from a list or specific location --> Don't search I will choose the driver to install --> Have Disk --> Copy manufacturer's files from c:/windows/system32 --> the specified location does not contain information about your hardware.
If instead of 'Don't search I will choose the driver to install' I select 'Include this location in the search C:\WINDOWS\system32' I'm presented with a choice between 2 files, both described as 'RioPort.com Rio500': C:\WINDOWS\inf\riousb.inf and C:\WINDOWS\inf\oem0.inf.

I've followed the instructions on the sonicblue link and yet some of the dlls mentioned as well as the Rioport entries in the registry keep reappearing. How come?

I've also tried to reinstall the previous drivers, upgraded to 9.0.145 (this is today's release you were refering to, right?), uninstalled and reinstalled the rio 500 plug-in (9.0.03) and still have the same problem (Media core problem and media center shut down).

Any suggestion?

Don't know if this can help but this is the beginning of the error report following the media core issue:

[lOth]

I think I figured out the .inf file the MC plug-in creates is riousb.inf in windows/inf/ (I guess that what was confusing to me is that this inf file describes de device as RioPort.com Rio 500 and I thought that was still the original file I was trying to get rid of). Even using that file to install the driver brought up the same problem as before. I'm getting a little bit despaired... It's for me THE thing that MC misses at this point to be perfect and kick all other programs' ass around...

[SteveG]

I was out today, but will give some attentioin to trying to get this solved for you tomorrow. At last check I could not duplicate it which may mean we have to chase driver issues which is a pain. I will post tomorrow.

Steve

[SteveG]

Can you get today's Rio Plugin (v 9.0.04) and then retest?

I found a bug that got introduced and fixed it. You may need to format your memory on the Rio if you are still having problems before getting this to work.

If you are still stuck, lets talk about drivers tomorrow. With the drivers I have installed, everything now works great.

Steve

[lOth]

Just tried it again with plug-in 9.0.04 and MC 9.0.147 on a freshly formatted Rio, still not working. Same 'media core problem'.  Ready for the drivers talk.

[SteveG]

Try getting the Plug-in I just posted (9.0.05) and see if things improve. I made some modifications and tested this on two clean XP machines.

Here is what I did..

1) Installed MC

2) Connected Rio (XP could not find drivers)

3) Installed Plugin.

4) Removed Rio from Device Manager and then reconnected.

5) XP found the drivers we include.

6) Ran MC with no problems.

The new Plugin is modified so it very well could make all the difference. If not, try as best you can to remove all of Rio's residue from your PC before trying again.

Steve

[lOth]

It worked! Thanks so much!
I don't see much of a difference with what I tried before. I think it all come from the revised plug in.
Thanks again  

[lOth]

OK, overall the plug in works fine but I guess a few things don't work quiet yet:

_ the sorting order is not saved (I've tried to set it to 'handheld path' but it always revert back to 'name', which is wrongly numbered 4th sorting criteria)

_ files that won't fit on the internal memory are not queued on the external memory

_ when using an external encoder and force file conversion is checked in the options, the 'available memory size exceeded' warning doesn't show up. I guess this is because the plug-in cannot infer the bitrate from the command line option. Can you think of a workaround?

_ dragging files from the queue to int mem to the queue to ext mem has three undesirable effects: 1) it brings up an "updating database" message 2) files dragged are copied (and not moved) to the queue to ext memory 3) ext queue is afterwards remembered as the default destination when you try to send files from the media library to the rio [all the same apply when you drag from ext to int]

_ canceling files conversion with an external encoder (xing in the instance) crashes Media center (media core encountered a problem etc.) I guess this might not be a problem specific to the plug-in.

I'll keep you posted if I find other ptoblems

[SteveG]

_ the sorting order is not saved (I've tried to set it to 'handheld path' but it always revert back to 'name', which is wrongly numbered 4th sorting criteria)
 

This is fixed in the next build of MC

_ files that won't fit on the internal memory are not queued on the external memory

The plugin is not designed to do this automatically. However, you can put the files on external memory by dragging them there.

_ when using an external encoder and force file conversion is checked in the options, the 'available memory size exceeded' warning doesn't show up. I guess this is because the plug-in cannot infer the bitrate from the command line option. Can you think of a workaround?

If the message did not show up, it was most likely because after the conversion there would be enough space. The existing code estimates the space needed after the conversion and responds with the message where appropriate.

_ dragging files from the queue to int mem to the queue to ext mem has three undesirable effects: 1) it brings up an "updating database" message 2) files dragged are copied (and not moved) to the queue to ext memory 3) ext queue is afterwards remembered as the default destination when you try to send files from the media library to the rio [all the same apply when you drag from ext to int]

This is disabled in the next build of MC so the problem will go away.

_ canceling files conversion with an external encoder (xing in the instance) crashes Media center (media core encountered a problem etc.) I guess this might not be a problem specific to the plug-in.

I could not duplicate this. What happens if you try to cancel a conversion apart from the transfer to Rio?

Thanks,

Steve

[lOth]

sorting order fixed! thanks a lot!

_ files that won't fit on the internal memory are not queued on the external memory:
 
SteveG:The plugin is not designed to do this automatically. However, you can put the files on external memory by dragging them there.

Too bad, that would be a really neat feature...

SteveG: If the message did not show up, it was most likely because after the conversion there would be enough space. The existing code estimates the space needed after the conversion and responds with the message where appropriate.

I think the plug-in doesn't estimate properly the space needed when you use an external encoder

_ dragging files from the queue to int mem to the queue to ext mem has three undesirable effects: 1) it brings up an "updating database" message 2) files dragged are copied (and not moved) to the queue to ext memory 3) ext queue is afterwards remembered as the default destination when you try to send files from the media library to the rio [all the same apply when you drag from ext to int]  

SteveG: This is disabled in the next build of MC so the problem will go away.

Too bad as well: that would be useful whenever a file doesn't fit on the internal mem it could be simply dragged to the queue to the ext. The possibility of having a statistic window on the right (like in the media library) would also make such an operation much easier.

ext queue is afterwards remembered as the default handheld destination when you try to send files from the media library to the rio

this problem is still there. In order to avoid it and to add another nice feature, would it be possible to have two separate items (rio 500 int & rio 500 ext) in the 'CD, DVD, Handhelds' right-click sub-menu. That would spare having to fumble around dragging files when your tree menu on the left is very long and need scrolling.

_ canceling files conversion with an external encoder (xing in the instance) crashes Media center (media core encountered a problem etc.) I guess this might not be a problem specific to the plug-in.  
 
SteveG: I could not duplicate this. What happens if you try to cancel a conversion apart from the transfer to Rio?

canceling conversion with ext encoder apart from the transfer to Rio worked fine.

I know you guys must be very busy with the final release and that the Rio 500 plug-in might not be your priority, but I believe that a good management of handheld devices can be a great asset in the face of other programs. As it stands right now MC is among the best programs to articulate a great media library with transfer capabilities to the Rio, but it's not yet THE best and that's what we all want!

[lOth]

I forgot to mention a serious problem I discovered: when there are already files on the int. mem (I've not tested with ext yet) trying to add files and transfer them brings up the media core error and crashes MC.

[SteveG]

In regards to the dynamic reassignment to Internal or External... this can be done, but I think it ends up being confusing. The point of the "Queue" area is to give the user control over where the files will go. I do not think it is a good idea for the program to make these determinations, even when space is unavailable.  As far as I can tell, the Plug-in does estimate space correctly, even when rencoding is enabled. As long as this works, I do not think we should reassign files. If the information is accurate, the user should reassign files based on the information (i.e. not enough space).

I did make a change in today's MC which should improve the crashing if you cancel the file conversion.

I cannot duplicate the problem you report of crashing when adding additional files. Please give more details.

Remembering the default path is by design.

I will look into adding  the additional right click items for the memory and folder types that you suggest.

Steve

[lOth]

The point of the "Queue" area is to give the user control over where the files will go.

fair enough...

If the information is accurate, the user should reassign files based on the information (i.e. not enough space).

Ok then, but would it be possible to somehow 'see' which files won't fit (by making them appear in a different color or separating them from the rest with an horizontal line) so that we can know which ones need to be reassigned to the ext. mem.

I cannot duplicate the problem you report of crashing when adding additional files. Please give more details.

If I transfer files to the Rio, say on the int. mem., and afterwards queue a few extra ones (that will of course fit on the available memory), still to the int. mem., I have the same problem as encountered when I first started the thread.

Remembering the default path is by design.

I will look into adding  the additional right click items for the memory and folder types that you suggest.

That would be great, that would allow us to turn around the remembering default path feature!

I did make a change in today's MC which should improve the crashing if you cancel the file conversion.

I've just installed the new build (9.0.156) and I'll let you know if the problem went away.

[SteveG]

Ok then, but would it be possible to somehow 'see' which files won't fit (by making them appear in a different color or separating them from the rest with an horizontal line) so that we can know which ones need to be reassigned to the ext. mem.

Currently the view of the files in the Queue is dynamic (i.e. whatever column you click defines the order of the files).  The files will be transferred in the order in which they were dropped on the Rio unless you right click on the Rio and select "Show Queued files only."  This option will allow you to order the files in whatever order you want them to appear on the Rio. Because you have control over what order to send the files, I do not think it will work to have a line which would presume a fixed transfer order.

If I transfer files to the Rio, say on the int. mem., and afterwards queue a few extra ones (that will of course fit on the available memory), still to the int. mem., I have the same problem as encountered when I first started the thread.

I cannot duplicate this. Does the crash occur during the file transfer? Does it happen every time? What if you add the files one by one?

In regards to the additional right-click items, this may have to wait until after the release of MC 9. To do this well would require changes that are larger than we want to undertake right now.

Steve