Bug 813977 - libdvdread fails to read DVDs with unexpected unicode filenames
Summary: libdvdread fails to read DVDs with unexpected unicode filenames
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: libdvdread
Version: 17
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dominik 'Rathann' Mierzejewski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-04-18 22:09 UTC by Chris Rankin
Modified: 2012-09-17 08:29 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 748671
Environment:
Last Closed: 2012-09-17 08:29:30 UTC
Type: ---


Attachments (Terms of Use)
enhanced patch from ubuntu forum (1.03 KB, patch)
2012-04-19 13:24 UTC, Honza Horak
no flags Details | Diff
Verbose output from xine (28.26 KB, text/plain)
2012-04-19 21:54 UTC, Chris Rankin
no flags Details

Description Chris Rankin 2012-04-18 22:09:13 UTC
+++ This bug was initially created as a clone of Bug #748671 +++

Created attachment 529993 [details]
patch

As described http://ubuntuforums.org/showthread.php?p=11254706, libdvdread (version 4.1.4-0.3.svn1188.fc15) fails to read DVDs with unicode filenames that are purposefully unusual.  The Thor DVD has this problem.

I've attached a patch for the code that was in the forum.  A libdvdread RPM built with the attached patch can handle the Thor DVD.

--- Additional comment from hhorak@redhat.com on 2012-01-10 06:45:25 EST ---

Andrew, could you try a new build which uses a bit different patch?
http://koji.fedoraproject.org/koji/buildinfo?buildID=270172

--- Additional comment from ajschult@verizon.net on 2012-01-14 23:00:16 EST ---

I unfortunately no longer have the offending DVD.  Others seem OK.

--- Additional comment from hhorak@redhat.com on 2012-01-16 03:11:00 EST ---

(In reply to comment #2)
> I unfortunately no longer have the offending DVD.  Others seem OK.

So I'm closing this for now. Feel free to re-open it if the problem shows up again.

Comment 1 Chris Rankin 2012-04-18 22:13:48 UTC
I have just purchased the Thor DVD and discovered that xine refuses to play it:

libdvdread: Using libdvdcss version 1.2.10 for DVD access
libdvdread: Invalid main menu IFO (VIDEO_TS.IFO).
libdvdread: Using libdvdcss version 1.2.10 for DVD access
libdvdread: Invalid main menu IFO (VIDEO_TS.IFO).

Googling reveals that I am not alone with this problem. I tried fixing this by upgrading my libdvdread to the F17 version (after recompiling the SRPM for F16):

libdvdread-4.2.0-2.fc16.x86_64
libdvdread-devel-4.2.0-2.fc16.x86_64

This hasn't helped xine, although I believe that it did allow libdvdcss to generate the keys this time.

Comment 2 Chris Rankin 2012-04-18 22:30:58 UTC
The libdvdread from F17 is sufficient for totem to play the Thor DVD, however. There is presumably still an extra wrinkle that needs to be solved for xine.

Comment 3 Honza Horak 2012-04-19 13:24:31 UTC
Created attachment 578651 [details]
enhanced patch from ubuntu forum

This patch is slightly modified version of a patch from Ubuntu forum [1]. 
Chris, can you, please, test it on the problematic DVD?
A scratch build for F17 available in [2]:

[1] http://ubuntuforums.org/showthread.php?p=11254706
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=4005386

Comment 4 Chris Rankin 2012-04-19 21:54:25 UTC
Created attachment 578795 [details]
Verbose output from xine

Sorry, it's the same result with libdvdread-4.2.0-2.unicode.fc17.i686.rpm.

Comment 5 Chris Rankin 2012-04-19 22:23:59 UTC
Aagh!! And the reason it's the same is because xine has its own internal DVD libs! This is a xine issue.

Comment 6 Honza Horak 2012-04-20 07:26:08 UTC
Hm, I believe xine uses xine-lib, which in turn uses libdvdread, but I can be wrong. CC-ing gxine's and xine-lib's maintainers, I'd like to ask them, does xine use libdvdread for reading DVDs?

Comment 7 Kevin Kofler 2012-04-20 08:41:14 UTC
xine-lib used to be built with a bundled libdvdread, I fixed that in xine-lib-1.1.20-1 (Nov 20, 2011). Now it uses the system version.

Comment 8 Kevin Kofler 2012-04-20 08:49:46 UTC
Quoting from https://bugzilla.redhat.com/attachment.cgi?id=578795 :
> Built with xine library 1.1.21 (1.1.21hg)
> Found xine library version: 1.1.21 (1.1.21hg).

That's not the Fedora xine-lib package. You may want to build your custom xine-lib with the --with-external-dvdnav configure flag, or apply the libdvdread patch also there, or just use the Fedora and RPM Fusion Free packaging of xine-lib and xine-lib-extras-freeworld.

The Fedora xine-lib package is not affected by this "bundled libdvd*" issue. (As I wrote in the previous comment, I already fixed it to use the system libdvdnav and libdvdread.)

Comment 9 Honza Horak 2012-04-20 08:58:49 UTC
Thanks for the notice, Kevin.

So I'm closing this bug, since it really doesn't look like there is anything wrong in Fedora packages. Feel free to re-open it if needed.

Comment 10 Kevin Kofler 2012-04-20 09:04:20 UTC
The patch is probably needed in our system libdvdread, though I cannot test it without having an offending DVD at hand.

Comment 11 Honza Horak 2012-05-14 15:38:33 UTC
Patch submitted to upstream:
http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2012-May/001714.html

Comment 12 Honza Horak 2012-09-17 06:37:38 UTC
Going through the discussion again, I'm curious if it is possible you tested it with older xine-lib (with bundled libdvdread), Chris? Could you, please, test it again with current xine-ilb, that uses libdvdread? Upstream believes this bug should be fixed in libdvdread-4.2.0.

Comment 13 Chris Rankin 2012-09-17 08:16:09 UTC
> Going through the discussion again, I'm curious if it is possible you tested
> it with older xine-lib (with bundled libdvdread), Chris?

Actually, I built my own xine-lib RPMs from the hg repository instead. And I'm fully aware that the system libdvdread fixes this problem too. Although xine *still* cannot play the "Thor" DVD - it now chokes on a different problem instead.

Totem plays it correctly, though. So there must still be a xine bug somewhere. (See Comment-5).

Comment 14 Honza Horak 2012-09-17 08:29:30 UTC
So we can close this, probably, since it was re-opened because of fixing libdvdread and there is no indication that libdvdread-4.2.0 has any problems.


Note You need to log in before you can comment on or make changes to this bug.