Messages

They don't have Linux version at all, protocol is closed. I doubt there will be support for it in the near future.

The next release (or beta) will have xine-lib 1.1.10.1 - this should be new enough for this

- To get the latest fixes I would recommend you to upgrade to beta5 or RC1 (not sure the exact name), which will be released on this week. This should make "DTS test" work, and I suggest you to continue tests with it.

- The ALSA output device (virtual) for writing to the SPDIF should be "asym_spdif", so try putting it in the Amarok configuration settings (LinuxMCE itself doesn't use Amarok, so you should configure it manually - http://opensusenewbie.blogspot.com/2007/04/how-to-get-amarok-and-kaffeine-to.html , but use "asym_spdif" instead of "plug:spdif").

Regarding #3 - don't know yet, please retest it after upgrading.

The copying progress is not shown when using ddrescue, because (iirc), disk_copy output it to the specific place from where the ripper script reads it. Looks like ddrescue doesn't do this.

Update: fix pushed into the trunk, will be available in the next nightly builds and betas/releases.

Ah, OK

Please post a mantis.

On my gentoo workstation, I tried the dd and vlc work-arounds, but without any success.  The ddrescue did work in ripping the dvd to hard disk:

Roy, does the dd fails for you even with conv=noerror switch?

Posted links for test .debs for the nightly builds (based on xine-lib 1.10.1)

Posted a note to the mantis issue with links to new debs of xine-lib 1.1.7 - please test it. Seeking/timecode should work now.

Hi,

I'll test this in the morning with a overnight build... sorry was not in the office much today.

Andrew

For the overnight build you will need different version of patched xine-lib, based on the 1.1.10.1, I'll post links tomorrow.

You don't need to update libdvdcss. It decrypts them well. It is a ripper that is failing. Different program, different place.

I'm yet again confused.  What do you mean "ripper"?  What exactly do I need to look for as a seemless solution?

OK, I'll try to shed some light here:
- when you have issues with new disks (copying them to Core AKA ripping), the separate tool is called that copies DVDs sectory by sector into a .dvd file. This is where it fails, according to your description (because of new protection with dummy sectors). I am calling this tool "ripper".

- when you are _playing_ the DVDs or .dvd files (ripped DVDs), the libdvdcss is used to decrypt the DVD for the playback

So, on the stage of copying (where it fails for you), libdvdcss is not used. Therefore it is no sense to look for libdvdcss updates, you should either use different ripper tool (which will not be seamless, but can work) or work on updating the current ripper to handle errors.

I would suggest you to try copying one of the failing DVDs from the commandline using
dd if=/dev/cdrom1 of=/home/linuxmce/testDisk.dvd conv=noerror
to see if it is possible to copy it at all, by suppressing errors (the "conv=noerror" should do this). It is for a start.

Posted a note to the mantis issue with links to new debs of xine-lib 1.1.7 - please test it. Seeking/timecode should work now.

You don't need to update libdvdcss. It decrypts them well. It is a ripper that is failing. Different program, different place.

Just a short info: when sending command MH_Play_Media to Media Plugin, you don't need to worry about things like "what is the ID of actual device that plays media in that area, etc.". In addition, assuming there can be >1 media handler for the media (now there are two already: for bluray files - MPlayer_Player, for the rest - Xine_Player), doing this manually is a a headache. Plus you have to bother about sending "Set Now Playing" messages to Orbiters.

So tschak999 is right - simply send the MH_Play_Media command to the Media_Plugin, specifying three things: URL of file you want to play, it's media type and EntArea - the system will do the rest by itself. By the way, if you are playing the file from the pluto_media table 'File' (i.e. the one that was scanned by UpdateMedia), you don't even need to pass the media type: send the URL in form "!F<PK_File>" where PK_File is the value of PK_File in File table, and EntArea to play - that's all.

the best way around would be to have a Video Menu, like we have a DVD Menu inside the LinuxMCE interface. Do you guys agree?

Yes There is mantis on this already: http://mantis.linuxmce.org/view.php?id=3836

Regarding this:

I have a few mkv files with both Chinese and English channels. I assume xine plays the default language, which is Chinese. However when I right click on the player and go to "Audio" -> "Channel" and select "eng", it continues to play in Chinese. After going mad for a few minutes, I decided to select "chi" and it finally decided to play in English 

Can you provide a sample file that has this error?