Print

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

[csimon]

I'm trying to work out how to rip CDs from a PC that is not the MC server, as it doesn't have an optical drive.  I am RDPing into the server and setting the RDP options to use the local CD drive.

This works in as far as the drive appears in My Computer on the MC server and I can view the .cda files on it, I can even map anotehr network drive to it. However, MC doesn't see it.  If I select Rip Disc, it says "Ripping is currently unavailable. Please ensure that a suitable optical drive is installed on this machine.".  I can go into Burning options (the drive is not listed...) and then select Redetect, but nothing happens.

The same thing happens if I plug in an external drive via USB to the local computer and then select that in RDP to use on the remote.

I have also tried plugging in the USB drive to the MC server, which works as far as it goes although this defeats the purpose of using the computer that's in a different room (as it has a proper computer desk, chair and a keyboard and monitor which is obviously easier for doing library work), but as soon as I RDP into it it seems MC loses the ability to see it again.

Is it possible to do this or, alternatively, will any other method work?

[mwillems]

I just tested and I can at least access cd drives local to the server in Teamviewer, so you may have better luck with a different RD/VNC solution than the one you're using?

FWIW, the way I rip is to create local "ripping" library on the client, switch libraries when ripping, transfer the finished files to a location watched by the server, and then switch back to the regular library.  It's not what you're looking for, but I find the workflow much easier than trying to do disk I/O over the network.

[csimon]

I just tested and I can at least access cd drives local to the server in Teamviewer, so you may have better luck with a different RD/VNC solution than the one you're using?

Just playing around with TeamViewer now. I did suspect RDP as being awkward because it creates virtual sessions and does funny things with devices whereas I suspect Teamviewer is more of a pure remote control of the current desktop.

FWIW, the way I rip is to create local "ripping" library on the client, switch libraries when ripping, transfer the finished files to a location watched by the server, and then switch back to the regular library.  It's not what you're looking for, but I find the workflow much easier than trying to do disk I/O over the network.

Yes - that's the way I currently do it, but getting fed up with either maintaining two libraries or having to constantly switch libraries.  I shouldn't think that network CD I/O would be too bad but would like to get it working just to see!  It's only a CD, takes about 10 minutes to rip on a local PC, I suspect the bottleneck is the CD read speed because copying a whole album of ripped files over my network takes about 2 seconds.

[csimon]

Hmm, it seems TeamViewer has the same issue, but is this a MC problem?

I've shared my optical drive to the MC server (the remote PC) but even without using TeamViewer and using that machgine directly, even though the remote optical drive appears as a mapped drive in My Computer (as a network location) and I can open it and view the .cda files, MC can't see it.

Does MC have to have a native, locally installed optical drive in order to read from it?

[csimon]

bump.

[tiberiuspv]

RDP (Windows remote desktop) is pretty paranoid and puts lots of restrictions on remote use of physical devices like CDROMs. Makes lots of sense for enterprise deployments, not so much at home! This one is (kind of) easy to solve (I had the same problem last week with my new Win8.1 PC...).

The solution is to modify the Local Group Policy as outlined in this article http://windows.microsoft.com/en-us/windows7/burn-a-cd-or-dvd-over-a-remote-connection. It shows how to do it for Win 7, Win 8(.1) follows the same model. You need to do this on the machine which has the CDROM, not the one on which you are running the remote desktop (though you can do it over the RDP connection...).
Quick summary:

    - Run gpedit.msc from an admin command tool
    - Double click Computer Configuration > Administrative Templates > System > Removable Storage Access > All Removable Storage: Allow direct access in remote sessions
    - Enable All Removable Storage: Allow direct access in remote sessions
    - Click OK and leave the Local Group Policy Editor
    - Run gpupdate.exe from the admin command tool (to apply the policy change)

You may need to exit & restart the RDP session afterwards.

I just tested it on my system, and ripped a CD in MC20 over RDP without problems. Good luck.

[csimon]

The solution is to modify the Local Group Policy as outlined in this article http://windows.microsoft.com/en-us/windows7/burn-a-cd-or-dvd-over-a-remote-connection.
....
I just tested it on my system, and ripped a CD in MC20 over RDP without problems. Good luck.

Thanks for the info, but before I try it, isn't this the other way around?  This is to allow the optical drive on the RDP target (the remote machine) to be accessed?  What I'm looking for is for the virtual session to be able to access the optical drive of the local PC. The MS article linked above states in its instructions for burning over RDP that this must be done on the computer that you're connecting to (the remote computer), and also: "Insert a blank recordable CD or DVD into the disc burner that's connected to the remote computer.".  I would like to be able to access the drive of the local computer, not the remote one, as in my case the remote one doesn't have an optical drive.

When you say you ripped a CD over RDP, which machine was the CD inserted into?  The PC you were sitting at where you loaded the RDP session (the local PC), or the PC where MC was running (the remote PC)?

I have been able to get the optical drive appearing in My Computer on the remote machine over RDP (by using the Local Resources oiption) and I can Explore it, but MC doesn't see it and doesn't recognise when a disc is inserted.  MC also doesn't see a remotely-connected USB drive. Is this a problem with MC? The reason I'm trying to do this is to get round the long-standing MC problem that the client is limited and cannot rip from a CD for some strange reason.

[tiberiuspv]

Ah, I had misunderstood the question. I suspect what you're looking for is not going to work because when the RDP client (the display) exports a device (the CD-ROM) to the server (where the full MC is running), it does not provide the full set of device features, on which rippers tend to depend. I will check on it tonight when I'm home.

[csimon]

OK, thanks!

But the other side of the coin is that, using another remote control product such as Teamviewer and sharing the drive via Windows, MC still couldn't see it. In fact, taking remote control and RDP out of the equation and just working on the PC that MC is installed on, MC doesn't seem able to see any optical drive that is not local, i.e. not motherboard-connected or USB-connected.  In Windows, you can map a network drive to a remote optical drive, whether it's a motherboard-connected one or USB-connected, and you can Explore it, but you can't rip from it using MC.  In my experiments anyway.  I don't know if this is a limitation with Windows or with MC.

[csimon]

The other methods I've thought of are:

1. A long USB cable (an active cable with built-in repeater) so that I can connect a USB drive locally to the MC PC but have the drive physically next to the computer I want to use, by having the cable trailing up the stairs!  Not sure of the length liomits on this.

2. A networked USB device server, which would sit next to the PC I want to use and creates a virtual USB port on the MC PC. This would be most convenient because it doesn't require extra cabling. But I can't be sure that MC won't still have problems with this.

3. Continue with the tedioius and pointless exercise of maintaining two media libraries and switching between them in order to rip.

If only ripping would be enabled on the MC client <sigh>.

[tiberiuspv]

Just played with it. It's definitely not going to work... The CDROM exported to the server looks like a network file system, not like an optical device. None of the rippers I tried (including MC) could see it as a CDROM.

On your other options:
1. You can't go very long with USB (5m max - probably not enough to go up the stairs...). There are options to carry USB over Cat5 twisted pair, which give you a better reach (note this is NOT running Ethernet, so don't connect the Cat5 to an Ethernet switch!). Speed may be a bit sluggish.

2. There are USB over IP devices (SIIG or StarTech for example - $40-$60) or software options (google USB over network). For some reason, the software options are more expensive than the hardware options (?). There is a good techie paper if you want the gory details at https://www.usenix.org/legacy/event/usenix05/tech/freenix/hirofuchi/hirofuchi.pdf on the underlying protocol which claims it works fine even for DVD burning, so hope is permitted. But I have no personal experience.

3. Maintaining two libraries is not that bad. Maintain the 'main' library on your music server, and a ripping library + a client library on your desktop. Rip on the desktop using the ripping library, check/correct the tags, copy the files over to the music server and import them to the main library. This is in effect what I do because I use a separate ripper (on the same machine), so the steps are essentially the same. But I spend a lot of time on tagging (classical music), so the overhead of the 2-step process is negligible for me.

Good luck.

[pubare]

tiberiuspv covered the general underlying reasons pretty well - to the best of my knowledge there aren't any remote access products that will do what you want.  The way Windows I/O works with optical devices, I'm not sure it's even technically possible.  USB device serving should certainly work (your option 2), but the most affordable and reliable option would be an external optical drive (I'm assuming an internal isn't an option) on the MC server - is there a reason that isn't possible?  As for the "option 1" you outlined below, I would recommend against it, even using the CAT5 / UTP extenders that are available - they tend to be "quirky" with "complex" I/O and could potentially affect the quality of the rip or exhibit inconsistent behavior.

[csimon]

but the most affordable and reliable option would be an external optical drive (I'm assuming an internal isn't an option) on the MC server - is there a reason that isn't possible? 

That's right, there is no option for an internal one. I have an external one, but one Pc is downstairs and the other is upstairs thenefore not convenient for ripping on one machine from the other, hence options 1 & 2.

[NJScope]

I struggled with this same problem for a week before finding a stable solution.  If your music server is running on Windows 7 Home then the ability to access a remote removable device like a CD/DVD burner has been eliminated in RDP.  Only Windows 7 Pro retains this ability as was previously available in XP.  I tried changing the Local Group Policy and installed some hacks but found my system to be unstable.   The solution was Thinstuff Remote Desktop Host ($15.90) which should fix your problem (again assuming that you are running Windows 7 Home or Windows 8 Basic).

[csimon]

Thanks, but I'm running Windows 7 Pro on both machines. RDP works in that it's possible to map the drive remotely and use it in the remote session, but it's only available as a filesystem and not an optical drive as such for ripping, playing or burning. Windows can see it, but MC can't.

[NJScope]

How about Windows Media Player?  Do you have full functionality to read, rip and burn on the music server?

[csimon]

How about Windows Media Player?  Do you have full functionality to read, rip and burn on the music server?

Sorry, I don't have any other software such as WMP set up on that machine, I want it to be as clean as possible. I guess I could try burning a CD remotely from Windows when I get home.

[84GCock]

Hello all, I'm a newbie here.  Only running the demo version of MC now.  I'm planning my HTPC (audio mainly) build and setup.

Saw this thread and was wondering the same thing as I already have a BR drive in my office desktop. 

One question, would running a seperate instance of MC on the PC that has the BR drive work?  If both instances can point to a single library I would think that would solve the problem.  Just a thought.   

[csimon]

If I understand you correctly, I think this amounts to the same thing as using a single instance of MC on the machine you want to rip on but change the library so it is using a local, unnetworked, scratch library to do the ripping. This then puts the files into a central location accessible from both machines then you have to go to the server machine to run an import to get the files into the networked library, complete the tagging and assign the cover art. Then switch the client machine back to the networked library.

i think what you're saying is that you'd use a second instance of MC with its own scratch library to do the ripping, but you'd still have to run that second instance, do the ripping, then go to the server to run a manual import and assign the cover art. It's all a bit of a faff really.

[84GCock]

This is what I'm thinking, a home network consisting of the following:

- HTPC (MC installed, all MC libraries on NAS)
- Network Attached Storage (All home computers have access to this)
- Desktop PC (MC installed, again all MC libraries on NAS shared with HTPC)

Can you not have both instances of MC populate one library on the NAS without switching locations?  If I have a local install shouldn't the software be able to recognize the BR drive?

[csimon]

It's possible to store the library on a NAS but JRiver do not recommend using MC with a library that is not local. If you do share the library this way then only the first MC instance to access it has write access, the other copies get read-only access. This might be fine if your office PC is the only one that does library maintenance and you don't want to do things like rate songs on the HTPC. If you don't leave the office Pc running all the time with MC loaded then I guess you'd have to shut down MC on the HTPC in order to do ripping on the office PC.

[84GCock]

Is the recommendation to store the library on only local disk for performance reasons only?

[csimon]

I think so. I do also know that sharing multi-user/multi-process flat-file databases over a network can be problematic when it's not a proper client/server database engine (e.g. MS Access!), leading to file locking problems and inconsistency, but I suspect MC gets round this by enforcing read-only for the secondary processes, making sure only one process has write access.

[84GCock]

Interesting, all things to keep in mind for my HTPC build.

Curious, what setup do you have for storage?  Attached USB drive or internal HD?

[mwillems]

Interesting, all things to keep in mind for my HTPC build.

Curious, what setup do you have for storage?  Attached USB drive or internal HD?

I use a NAS for storage myself.

Just to make sure there's no confusion: media files are fine on a NAS; it's MC's Library (aka database) that should be local on a fast drive.  The term Library is equivocal and can lead to confusion at first.  MC's Library isn't very big so it's easy to make space for it.

[84GCock]

Thanks for pointing that out.

I do see that the file locations are diff from the library location.  So you do use NAS (Network) and not attached HD (USB)?

[mwillems]

Thanks for pointing that out.

I do see that the file locations are diff from the library location.  So you do use NAS (Network) and not attached HD (USB)?

I use a homemade NAS on a Gb switch  for data rather than local storage (but to be clear I keep the library database on an internal SSD).  

My personal experience has been that USB spinning disk hard drives (HDDs) are significantly slower and more failure prone than conventional internal HDDs, so I try to avoid USB drives whenever possible.  

As for NAS vs. USB, in terms of speed, USB3 is theoretically faster than an ethernet connection if the drive supports it, but most HDD's have a max read speed in the 80-100MB/s range.  That won't saturate a Gb ethernet connection, so there isn't even a theoretical speed advantage to USB3 for most HDDs. And networked storage makes the data accessible all over the house without having to leave a power-hungry PC on, which is also nice.  

Two Caveats:

1) If you can't wire up a hypothetical NAS, I'd be more inclined to look back into local storage.  WiFi (even newish AC WiFi) kind of sucks if you need significant bandwidth (like for HD video).  The router manufacturers quote ridiculous bandwidth stats, but they're not really achievable in most real world conditions.

2) If you only have one PC that will use the data, local storage probably makes the most sense from a power consumption standpoint (and cost, and ease of use, and ...), but internal drives are preferable to USB (both for speed and reliability) if you can get a good price on the big ones.  

[84GCock]

My plan is to use a wired NAS for several reasons, never considered WiFi b/c of performance/reliability.  If I didn't go with NAS you think internal drives would be better than USB?  I ask the question thinking about the noise that would be introduced by internal HDs? 

I plan to use SPDIF out on the HTPC mb to feed my Cambridge Audio 840CD which has a built in DAC.  The rest of my rig is a McIntosh C220 tube pre, Pass Labs X150 amp and Martin Logan Ascent electrostatics.     

[csimon]

Curious, what setup do you have for storage?  Attached USB drive or internal HD?

My physical media files are on a NAS (Synology). I have a small, silent low-power PC in the living room as the MC server. My general purpose "powerful" PC is upstairs.  But the living room PC does not have an optical drive.

[mwillems]

My plan is to use a wired NAS for several reasons, never considered WiFi b/c of performance/reliability.  If I didn't go with NAS you think internal drives would be better than USB?  I ask the question thinking about the noise that would be introduced by internal HDs?  
  

Do you mean mechanical or electrical noise?

If mechanical, I don't think there's any reason to think an external would be quieter.  In my experience it's been the opposite (unless you leave the external unplugged most of the time).  Internal drives can be mounted in a way that damps vibration, and they're inside a case with metal walls.  The external drives are typically mechanically identical (with a USB controller grafted on), but crammed into a cheap plastic housing with no real damping whatsoever.  So if they spin at the same speed, the external will be as loud or louder.

If electrical, I'm not sure that a USB based electrical connection will necessarily be less prone to introduce noise than a SATA connection, but maybe you're thinking about the power supply?  Some external drives do have their own power supply, which could theoretically reduce electrical noise, but could also introduce a ground loop, so it's kind of a crapshoot either way.  It shouldn't really matter with a decent DAC anyway and if you have an optical SPDIF it definitely won't matter.

My physical media files are on a NAS (Synology). I have a small, silent low-power PC in the living room as the MC server. My general purpose "powerful" PC is upstairs.  But the living room PC does not have an optical drive.

Sorry about the threadjack csimon;  for what it's worth, I find it a bit less of a faff to do all of my tagging and cover art manipulation in the scratch local library.  When I'm done, I just use the rename/copy function to move the files to the "watch location" and the auto-import on the real library picks them up with no trouble.  The only added work in my method is switching the library and moving the files, which is pretty minor.

[csimon]

for what it's worth, I find it a bit less of a faff to do all of my tagging and cover art manipulation in the scratch local library.  When I'm done, I just use the rename/copy function to move the files to the "watch location" and the auto-import on the real library picks them up with no trouble.  The only added work in my method is switching the library and moving the files, which is pretty minor.

I've ended up maintaining two separate libraries and not using library server, which saves reloading the libraries.  All ripping and tagging done is upstairs, files are automatically ripped to the NAS but I may have to do some manual moving sometimes, and I then run a manual import for the other PC as way back I ran into problems using auto import when it would start importing video files before they'd completely saved.  But I'm now running into problems with changing tags on either machine - doing a manual import on the other used to sort it out but now I find it's not working. Perhaps an Update Tags from File would work, but I was then starting to think about library server again which should hopefully sync changes (but I ran into problems last time I tried to get two-way syncs working...). That of course gave me the problem of switching libraries for ripping or trying to use a remote desktop to do it directly on the other PC, but using the local CD drive, but as documented this isn't working.

It's all a faff whichever way you do it, I seem to hit brick walls whatever I try.  You may well be right, switching libraries and running extra imports may be the "least troublesome" way, but it would all be a lot simpler if ripping was enabled on the client. I just don't understand what is so difficult about writing a record to the remote database, no reason has been given for why the function is disabled.  It would probably be done via the "background sync" process anyway as any normal synched change would be done, I don't see why this update is any different from any other update that MC already does to the server from the client, even if the sync process is convoluted.

[mwillems]

It's all a faff whichever way you do it, I seem to hit brick walls whatever I try.  You may well be right, switching libraries and running extra imports may be the "least troublesome" way

You shouldn't need to run extra imports; if auto-import is on on the server (and only on the server), just make sure that the files are ready to go before you move them to the NAS and all should be well (I've never had an issue doing it that way).

but it would all be a lot simpler if ripping was enabled on the client. I just don't understand what is so difficult about writing a record to the remote database, no reason has been given for why the function is disabled.  It would probably be done via the "background sync" process anyway as any normal synched change would be done, I don't see why this update is any different from any other update that MC already does to the server from the client, even if the sync process is convoluted.

I agree it would be easier; I think the ripping issue is a part of the general issue that clients cannot import anything on the server.  I'm not sure why from a technical standpoint that's the case, but at the moment the client cannot import anything into the library, so why should ripping be any different?

For me, it's in the same category as being unable to change cover art from a client.  It's an odd corner of the software, but that's the way it is for the moment.

[csimon]

You shouldn't need to run extra imports; if auto-import is on on the server (and only on the server), just make sure that the files are ready to go before you move them to the NAS and all should be well (I've never had an issue doing it that way).

Never had a problem with audio files actually, they're probably small and quick enough, it was video files that would auto-import while they were still in the process of being copied to the watched location, causing MC to label them as "bad" and I would have to go through hoops to remove them from the bad database and import them again.  But at the moment, my ripping is set to go straight to the watched location so I don't have to do any manual moving.  So it's a case of running a manual import vs. doing a manual move - it doesn't cut out any steps! I think the manual import is less hassle because it's done in two clicks with no brainwork required!

Ripping a CD shouldn't actually be "troublesome" at all, it should all be a straightforward workflow.

Anyway, I've bought a USB over IP server today but haven't had time yet to set it up.  If it works, it will mean I could leave the system in client/server all the time without switching libraries and still rip on the remote machine using a local CD drive.  The faff in this case would be to have to load up a remote desktop application.  Even that's fraught with gotchas, as the built-in RDP leaves the desktop on the remote machine locked and you have to go to it and enter username and password.  Currently investigating TeamViewer...

[csimon]

I'm not sure why from a technical standpoint that's the case, but at the moment the client cannot import anything into the library, so why should ripping be any different?

It sounds like the client is able to make record changes on the server but cannot insert new records.  That's the similarity between importing and ripping and explains why if one can't be done then neither can the other.

But on the other hand, from a database point of view there should be no technical difference between updates, inserts and deletes.

[csimon]

OMG - the USB over IP server works!  Literally plug n play, it just worked on installing the driver. USB devices plugged into it can be connected and disconnected just like any normal USB device and MC is able to see the remote BR drive as a proper optical disc and can rip from it. Just done 2 new CDs.

[mwillems]

Excellent!  If only my server weren't in a closet 

[tiberiuspv]

Very good! Which USB over IP solution did you end up using?

[csimon]

Coolead. http://www.amazon.co.uk/gp/product/B00JRO0QB8

There was a slightly more expensive one by DLink which is gigabit (this one is only fast ethernet) but there were some reviews that seemed to have common issues with Windows 7 and I decided fast ethernet was good enough for ripping. Nice, compact unit that looks good. It strangely came with a cleaning cloth as described on the product page, like the kind you get with glasses, not sure what that was intended for!

Just had one problem so far with the driver that doesn't seem to wake properly after the computer has been to sleep, so I need to play arounbd with that a bit more.

I also intend to plug a cheap USB soundcard dongle into it and hang a microphone off it for use with VoxCommando so I can voice-control MC (running on the downstairs PC) from upstairs! (I distribute audio output to multiple rooms rather than trying to synchronise playback across multiple MC zones).  Also plug in small PC speakers to that to have the voice output from VoxCommando too.  You can run multiple instances of VoxCommando which connect to different microphones and speakers for independant control from multiple locations.

[tiberiuspv]

Dirt cheap (this may be why they include a cleaning cloth :-). 100M Ethernet should be enough, a 1x CDROM is < 1.5 Mbps, a 48x CDROM is < 70 Mbps. Not much headroom, so I would not guarantee 48x speed, but then very few CDROMs deliver 48x speed, marketing claims notwithstanding...
Keep us posted how this works out for you in practice, this looks like a cool solution. I may follow the same path for similar reasons - main PC upstairs, music room with dedicated music PC (JRiver server) downstairs. I usually rip & tag downstairs, this would give me flexibility.

[csimon]

I don't think I've ever seen MC ripping at more than about 12x!  May be my drives, but anyway, I don't think I shall be saturating my network with ripping.

[csimon]

Here's another interesting device for those situations where the MC client just doesn't cut it! A bit more expensive but it seems to mimic a thin client for Windows in that it mirrors your desktop to its HDMI port as well as having four USB-over-IP ports. Probably not necessary if you're already happy with a remote desktop solution but may be neater.

http://www.trustedreviews.com/nzxt-doko-review