From: Godwin S. <gst...@sp...> - 2003-12-21 15:04:43
|
Hi, I have a couple of problems with DVD playback using Xine which I'm hoping you can help me with. Advance apologies if this has alrady been answered - sourceforge.net appears down from here so I can't search the list archives first. Problem 1: One DVD refuses to play back. The movie distributor's trailer is played back fine but as soon as the movie starts, I get a dialog box with this error message: The source can't be read. Maybe you don't have enough rights for this, or source doesn't contain data (e.g. not disc in drive). (Expected NAV packet but none found.) Clicking on the "More" button gets this (screenshot of the dialog box): http://linux.sgms-centre.com/xine-error.png The "plugin" tab simply enumerates the xine plugins found, and the "trace" tab is empty. The same DVD plays back fine on a set-top DVD player, and also using the same hardware and a Windows DVD playback application (PowerDVD) both under W98 and W2000. Problem 2: The "extra features" provided with some (but not all) DVDs are extremely jerky, even if the movie itself plays back fine. Both the image and sound freeze, not together, for a fraction of a second every second or two (apparently random delay between freezes). After a while, audio and video are completely out of sync. Once again, this doesn't happen on a set-top DVD player, but I haven't been able to try using PowerDVD since I removed Windows altogether from my system before acquiring this DVD. Hardware: DVD drive: SAMSUNG DVD-ROM SD-616Q, ATAPI CD/DVD-ROM drive, Firmware revision "F401" Transfer mode: UDMA-33. CPU: Intel Celeron 433. Output: Hollywood+ (=DXR3) Software: xine-ui-0.9.22 xine-lib-1-rc3 libdvdcss-1.2.8 em8300-0.13.0 Many thanks in advance for any light you can shed on this! -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- guru, n: A computer owner who can read the manual. |
From: Michael R. <mr...@us...> - 2003-12-21 15:27:44
|
Hi, > Problem 1: > > One DVD refuses to play back. The movie distributor's trailer is > played back fine but as soon as the movie starts, I get a dialog box > with this error message: > > The source can't be read. > Maybe you don't have enough rights for this, or source doesn't > contain data (e.g. not disc in drive). (Expected NAV packet but none > found.) This is most likely a bug in xine, maybe in libdvdnav. Could you compile xine-lib with DVD tracing? You do this by modifying the file xine-lib/src/input/libdvdnav/dvdnav_internal.h, line 43; from: /* #define TRACE */ to #define TRACE Then recompile and reinstall xine-lib. When you play your DVD now, a lot of debug information will be printed on console. Send the entire output of the failing DVD together with a copy of the DVD's .IFO files here. (Or, if you think it is too big for the list, to me privately.) > Problem 2: > > The "extra features" provided with some (but not all) DVDs are > extremely jerky, even if the movie itself plays back fine. Both the > image and sound freeze, not together, for a fraction of a second > every second or two (apparently random delay between freezes). After > a while, audio and video are completely out of sync. I assume this is with the DXR3? Does this happen with software playback as well? If not, this is most likely a type of broken disc I have already seen. Try enabling the config entry dxr3.correct_durations. This should cure the problem after a while. Michael -- "Hey, it's Unix! I know this!" -Lex, Jurassic park. |
From: Godwin S. <gst...@bo...> - 2003-12-21 16:24:32
|
Sun, 21 Dec 2003 16:27:36 +0100 scripsit Michael Roitzsch: > This is most likely a bug in xine, maybe in libdvdnav. Could you compile > xine-lib with DVD tracing? You do this by modifying the file > xine-lib/src/input/libdvdnav/dvdnav_internal.h, line 43; from: > > /* #define TRACE */ > > to > > #define TRACE Translation: "uncomment the directive on line 43" :o) > Then recompile and reinstall xine-lib. When you play your DVD now, a lot > of debug information will be printed on console. Send the entire output > of the failing DVD together with a copy of the DVD's .IFO files here. > (Or, if you think it is too big for the list, to me privately.) Done. All the data is available here: http://linux.sgms-centre.com/xine-bug.tar.bz2 69767 bytes MD5: 680b3e0101c3684e8448092293e0ea13 xine-bug.tar.bz2 > I assume this is with the DXR3? Correct. > Does this happen with software playback as well? I think so, but I can't be sure. It's hard to tell because software playback on my system in Linux isn't even worth attempting (hence the acquisition of the DXR3 in the first place). The audio feed seems pretty stable, more so than when using the DXR3, but the video feed is as jerky as you'd expect it to be on an underpowered system (Celeron 433). > If not, this is most likely a type of broken disc I have already seen. Try > enabling the config entry dxr3.correct_durations. This should cure the > problem after a while. Yep. That did it. Thanks! Let me know if you need more information for problem #1. Oh, and while I think of it, xine-ui invariably hangs when stopping DVD playback through the DXR3, whether you use "stop" or any other function which causes playback to stop (like trying to exit xine-ui). The only way to get rid of it thereafter is to "killall -s KILL xine". Using software playback (-V xv) this doesn't happen. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Sign spotted in an office: AFTER TEA BREAK STAFF SHOULD EMPTY THE TEAPOT AND STAND UPSIDE DOWN ON THE DRAINING BOARD |
From: Michael R. <mr...@us...> - 2003-12-27 13:28:36
Attachments:
dump-sectors.patch
em8300-cvs-fix.patch
|
Hi, > > /* #define TRACE */ > > > > to > > > > #define TRACE > > Translation: "uncomment the directive on line 43" :o) Right. I see I can be less verbose. ;) > All the data is available here: > > http://linux.sgms-centre.com/xine-bug.tar.bz2 > 69767 bytes > MD5: 680b3e0101c3684e8448092293e0ea13 xine-bug.tar.bz2 Thanks for that. I looked over it but could not find any obvious problem. I need additional information about what sectors are being read. Could you apply the attached patch to xine-lib and reinstall, leaving tracing enabled. Then send the output again. > Oh, and while I think of it, xine-ui invariably hangs when stopping > DVD playback through the DXR3, whether you use "stop" or any other > function which causes playback to stop (like trying to exit xine-ui). > The only way to get rid of it thereafter is to "killall -s KILL > xine". This is a bug in the em8300 kernel module as of 0.13.0. You can try using their current CVS, but this needs the second patch I attached to work with xine. This patch has already been submitted to dxr3-devel. Michael -- The computer revolution is over. The computers won. |
From: Godwin S. <gst...@sp...> - 2003-12-27 14:15:17
|
Sat, 27 Dec 2003 14:28:15 +0100 scripsit Michael Roitzsch: > > Translation: "uncomment the directive on line 43" :o) > > Right. I see I can be less verbose. ;) Better safe than sorry :) > Thanks for that. I looked over it but could not find any obvious > problem. I need additional information about what sectors are being > read. Could you apply the attached patch to xine-lib and reinstall, > leaving tracing enabled. Then send the output again. Available here: http://linux.sgms-centre.com/with_print_requested_sector.txt.bz2 13767 bytes (expands to over 300KB...) MD5: cc61330f08c97149fcf5358ab6dd5ce9 with_print_requested_sector.txt.bz2 Sector 8616 appears to be the last one requested on each of the runs I tried. > > Oh, and while I think of it, xine-ui invariably hangs... > > This is a bug in the em8300 kernel module as of 0.13.0. You can try > using their current CVS, but this needs the second patch I attached to > work with xine. This patch has already been submitted to dxr3-devel. Thanks for that info. There isn't much about this on dxr3.sourceforge.net, is there another place I should be looking? Also, I've started attempting to port em8300 to the 2.6 kernel. Is anyone else having a go at this - you know, pooling our resources and all that, there's no point in everyone doing everything... -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- The quickest way to double your money is to fold it in half and put it back in your pocket. |
From: Michael R. <mr...@us...> - 2003-12-27 16:20:26
|
Hi, > > Thanks for that. I looked over it but could not find any obvious > > problem. I need additional information about what sectors are being > > read. Could you apply the attached patch to xine-lib and reinstall, > > leaving tracing enabled. Then send the output again. > > Available here: > > http://linux.sgms-centre.com/with_print_requested_sector.txt.bz2 > 13767 bytes (expands to over 300KB...) > MD5: cc61330f08c97149fcf5358ab6dd5ce9 > with_print_requested_sector.txt.bz2 > > Sector 8616 appears to be the last one requested on each of the runs > I tried. There should be one other sector request after this, since the output continues after 8616 (which is btw the number I expected :) ), so 8616 was read and dispatched correctly. The file appears to be truncated. Could you try to avoid that? Maybe launching from console and just posting the additional lines here. > > This is a bug in the em8300 kernel module as of 0.13.0. You can try > > using their current CVS, but this needs the second patch I attached > > to work with xine. This patch has already been submitted to > > dxr3-devel. > > Thanks for that info. There isn't much about this on > dxr3.sourceforge.net, is there another place I should be looking? There is a posting from me on the dxr3-devel list. > Also, I've started attempting to port em8300 to the 2.6 kernel. Is > anyone else having a go at this - you know, pooling our resources and > all that, there's no point in everyone doing everything... There is already a patch available. It has also been posted on dxr3-devel. Michael -- die_if_kernel("Penguin instruction from Penguin mode??!?!", regs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c |
From: Godwin S. <gst...@sp...> - 2003-12-27 16:31:04
|
Sat, 27 Dec 2003 17:20:19 +0100 scripsit Michael Roitzsch: > The file appears to be truncated. Could you try to avoid that? Maybe > launching from console and just posting the additional lines here. No. xine crashes at that point and there is no further output. I did try this several times just to make sure. I *have* been launching from the console, like this: $ xine -V dxr3 -s dvd | tee outputfile.txt (so that I can see what is being dumped into the output file) It could have something to do with buffering and the amount of data. I'm patching your patch so that it only dumps the "sector requested" message if n>8600 and I'll resend an output. > > Thanks for that info. There isn't much about this on > > dxr3.sourceforge.net, is there another place I should be looking? > > There is a posting from me on the dxr3-devel list. Thanks. I'll have to look for it. > > Also, I've started attempting to port em8300 to the 2.6 kernel. Is > > anyone else having a go at this - you know, pooling our resources and > > all that, there's no point in everyone doing everything... > > There is already a patch available. It has also been posted on > dxr3-devel. Once again, I'll have to look for it. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Okay, so what is the speed of dark? |
From: Godwin S. <gst...@sp...> - 2003-12-27 16:53:34
Attachments:
with_print_requested_sector_2.txt
|
Sat, 27 Dec 2003 17:20:19 +0100 scripsit Michael Roitzsch: > There should be one other sector request after this, since the output > continues after 8616 (which is btw the number I expected :) ), so 8616 > was read and dispatched correctly. > The file appears to be truncated. Could you try to avoid that? Maybe > launching from console and just posting the additional lines here. This should be better (attached since it is only 23k). BTW, I can't look at the dxr3-devel list archives, sourceforge.net times out here. Could you mail me (off-list if you prefer) the 2.6 kernel patch to em8300-0.13.0? I'd like to see where I was going wrong in my (as yet) unsuccessful attempt :) -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- What's the definition of a will? (It's a dead giveaway). |
From: Michael R. <mr...@us...> - 2003-12-27 17:35:37
|
Hi, > > The file appears to be truncated. Could you try to avoid that? > > Maybe launching from console and just posting the additional lines > > here. > > No. xine crashes at that point and there is no further output. I did > try this several times just to make sure. I *have* been launching > from the console, like this: > > $ xine -V dxr3 -s dvd | tee outputfile.txt > > (so that I can see what is being dumped into the output file) That's strange. It should not crash here just because of one additional printf. What happens without the tee, just with "xine -V dxr3 -s dvd" and the original patch? > It could have something to do with buffering and the amount of data. > I'm patching your patch so that it only dumps the "sector requested" > message if n>8600 and I'll resend an output. Problem is that I expect the last (and failing) sector read to be at n=0, so the patch you intend wouldn't help. Michael -- "Order is for the simple-minded - it's the genius who rules the chaos." -Sir Arthur Conan Doyle |
From: Godwin S. <gst...@sp...> - 2003-12-27 17:52:55
|
Sat, 27 Dec 2003 18:32:12 +0100 scripsit Michael Roitzsch: > Problem is that I expect the last (and failing) sector read to be at > n=0, so the patch you intend wouldn't help. OK. What I'll do is unpatch your patch and do rerun xine. This time I'll send xine a SIGQUIT while the error dialog is still displayed. This should make xine quit gracefully and flush its buffers before exiting. Your guess was correct. Does this mean that there's a bug in xine-lib or that the DVD is b0rked in some way that set-top players and commercial software tolerate? (033) 71 00 00 04 65 6e 00 00 | g[4] = 0x656e ("en") (034) 51 20 00 80 00 00 03 04 | if (g[3] == g[4]) Audio Stream Number (SRPM:1) = 0x0 (035) 51 20 00 00 80 00 03 04 | if (g[3] == g[4]) Sub-picture Stream Number (SRPM:2) = 0x0 (036) 71 00 00 04 64 65 00 00 | g[4] = 0x6465 ("de") (037) 51 20 00 81 00 00 03 04 | if (g[3] == g[4]) Audio Stream Number (SRPM:1) = 0x1 (038) 51 20 00 00 80 00 03 04 | if (g[3] == g[4]) Sub-picture Stream Number (SRPM:2) = 0x0 (039) 71 00 00 04 66 72 00 00 | g[4] = 0x6672 ("fr") (040) 51 20 00 82 00 00 03 04 | if (g[3] == g[4]) Audio Stream Number (SRPM:1) = 0x2 (041) 51 20 00 00 cf 00 03 04 | if (g[3] == g[4]) Sub-picture Stream Number (SRPM:2) = 0x4f (042) 71 00 00 04 69 74 00 00 | g[4] = 0x6974 ("it") (043) 51 20 00 83 00 00 03 04 | if (g[3] == g[4]) Audio Stream Number (SRPM:1) = 0x3 (044) 51 20 00 00 80 00 03 04 | if (g[3] == g[4]) Sub-picture Stream Number (SRPM:2) = 0x0 (045) 71 00 00 04 65 73 00 00 | g[4] = 0x6573 ("es") (046) 51 20 00 84 00 00 03 04 | if (g[3] == g[4]) Audio Stream Number (SRPM:1) = 0x4 (047) 51 20 00 00 d0 00 03 04 | if (g[3] == g[4]) Sub-picture Stream Number (SRPM:2) = 0x50 (048) 71 00 00 05 00 05 00 00 | g[5] = 0x5 libdvdnav: Registers after transaction libdvdnav: # 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | libdvdnav: SRPMS: 656e|0000|0000|0001|0001|0001|0001|0001|0400|0000|0000|0000|5553|000f|0100|0000|656e|0000|656e|0000|0002|0000|0000|0000| libdvdnav: GRPMS: 0000|0000|0000|656e|6573|0005|0001|0001|0000|0000|0001|0000|0000|0000|0000|0000| libdvdnav: Gmode: 0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000| libdvdnav: Gtime: 0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000|0000| libdvdnav: PGC pre commands didn't do a Jump, Link or Call libdvdnav: play_PG: (vm->state).pgN (1) libdvdnav: play_Cell: (vm->state).cellN (1) libdvdnav: ************ this chapter FOUND! libdvdnav: VTS_PTT_SRPT - Title 1 part 1: PGC: 1 PG: 1 libdvdnav: Cell should restart here libdvdnav: After printout starts: libdvdnav: Video Title Domain: - libdvdnav: VTS:1 PGC:1 PG:1 CELL:1 BLOCK:0 VTS_TTN:1 TTN:1 TT_PGCN:1 libdvdnav: After printout ends. libdvdnav: ************ this chapter FOUND! libdvdnav: VTS_PTT_SRPT - Title 1 part 1: PGC: 1 PG: 1 libdvdnav: sector 0 requested -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- "I don't understand that attitude. Don't we want email that has dancing bears, cute little videos, musical tunes, animated waving hands, sixty fonts, and looks like it's been done with crayolas? Good grief, man, think like a three year old!" -- Norm Reitzel discussing HTML email |
From: Michael R. <mr...@us...> - 2003-12-27 17:35:56
|
Hi again, > BTW, I can't look at the dxr3-devel list archives, sourceforge.net > times out here. Could you mail me (off-list if you prefer) the 2.6 > kernel patch to em8300-0.13.0? I'd like to see where I was going > wrong in my (as yet) unsuccessful attempt :) I am not using 2.6 yet, but this one was on the list: http://www.jburgess.uklinux.net/linux-2.6.0-test7-dxr3.patch.bz2 Michael -- "In my opinion MS is a lot better at making money than it is at making good operating systems" -Linus Torvalds, August 1997 |
From: Godwin S. <gst...@sp...> - 2003-12-27 18:03:54
|
Sat, 27 Dec 2003 18:32:54 +0100 scripsit Michael Roitzsch: > I am not using 2.6 yet, but this one was on the list: > http://www.jburgess.uklinux.net/linux-2.6.0-test7-dxr3.patch.bz2 Thanks for that. BTW the code has been updated - kind of...: http://www.jburgess.uklinux.net/linux-2.6.0-test9-dxr3.patch.bz2 I have been using the stable 2.6.0 kernel rather than one of the test kernels (which I couldn't get to boot until test9 anyway...) so I'll see if using a patch against a -test kernel creates problems. Most of the time, however, I use 2.4.23. This *will* change if I can get the HW+ to work in 2.6.0. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. -- Howard Aiken |
From: Michael R. <mr...@us...> - 2003-12-27 18:34:25
|
Hi, > Your guess was correct. Does this mean that there's a bug in xine-lib > or that the DVD is b0rked in some way that set-top players and > commercial software tolerate? [snip] > libdvdnav: sector 0 requested So far everything is fine except that the disc does not play. Sector 0 is the correct start for the next data, nothing wrong with this. The exact error in the dialog was "Expected NAV packet, but none found", right? So somehow sector 0 is supposed to be a NAV packet, but libdvdnav says it is not. I would like to see a copy of this NAV packet. I think you can obtain it by mounting the disc and typing dd if=/mnt/dvd/VIDEO_TS/VTS_01_1.VOB bs=2048 count=1 > NAV Michael -- Who the fuck is "General Failure", and why is he reading my disk? |
From: Godwin S. <gst...@sp...> - 2003-12-28 05:56:51
Attachments:
NAV
|
Sat, 27 Dec 2003 19:26:38 +0100 scripsit Michael Roitzsch: > So far everything is fine except that the disc does not play. Uhh.. Yep. You could put it that way :) > Sector 0 is the correct start for the next data, nothing wrong with this. > The exact error in the dialog was "Expected NAV packet, but none found", > right? Right. > So somehow sector 0 is supposed to be a NAV packet, but > libdvdnav says it is not. I would like to see a copy of this NAV > packet. I think you can obtain it by mounting the disc and typing > > dd if=/mnt/dvd/VIDEO_TS/VTS_01_1.VOB bs=2048 count=1 > NAV First 2048 bytes of vts_01_1.vob attached in a file called NAV. Here's a hexdump of it in case that helps: $ hexdump -C NAV 00000000 00 00 01 ba 44 00 04 00 04 01 01 89 c3 f8 00 00 |...ºD.......Ãø..| 00000010 01 bb 00 12 80 c4 e1 14 e1 7f b9 e0 e8 b8 c0 20 |.»...Äá.á.¹àèžÀ | 00000020 bd e0 3a bf e0 02 00 00 01 bf 03 d4 00 00 00 00 |œà:¿à....¿.Ô....| 00000030 00 40 00 00 00 00 00 00 00 00 00 7c 74 00 01 25 |.@.........|t..%| 00000040 34 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |4.......@.......| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 00 00 01 bf 03 fa 01 00 00 00 00 00 00 00 00 00 |...¿.ú..........| 00000410 00 00 5d 00 00 00 0a 00 00 00 15 00 00 00 27 00 |..]...........'.| 00000420 01 00 01 00 00 00 40 00 00 00 00 00 00 00 00 00 |......@.........| 00000430 00 00 00 00 00 7c 74 2b fc 0b 54 00 00 00 00 00 |.....|t+ü.T.....| 00000440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000004f0 00 80 00 00 5e c0 00 c6 ea c0 00 53 a8 c0 00 22 |....^À.ÆêÀ.SšÀ."| 00000500 d6 c0 00 0e 2e 80 00 09 d2 80 00 08 f7 80 00 08 |ÖÀ......Ò...÷...| 00000510 32 80 00 07 73 80 00 06 b5 80 00 05 ec 80 00 05 |2...s...µ...ì...| 00000520 20 80 00 04 54 80 00 03 8a 80 00 02 cf 80 00 02 | ...T.......Ï...| 00000530 1b 80 00 01 7a 80 00 00 f9 80 00 00 b6 80 00 00 |....z...ù...¶...| 00000540 5e 80 00 00 5e 3f ff ff ff 3f ff ff ff 3f ff ff |^...^?ÿÿÿ?ÿÿÿ?ÿÿ| 00000550 ff 3f ff ff ff 3f ff ff ff 3f ff ff ff 3f ff ff |ÿ?ÿÿÿ?ÿÿÿ?ÿÿÿ?ÿÿ| * 00000590 ff 3f ff ff ff bf ff ff ff 00 54 00 55 00 56 00 |ÿ?ÿÿÿ¿ÿÿÿ.T.U.V.| 000005a0 57 00 58 00 00 00 00 00 00 7f ff ff ff 7f ff ff |W.X.......ÿÿÿ.ÿÿ| 000005b0 ff 7f ff ff ff 7f ff ff ff 7f ff ff ff 7f ff ff |ÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ.ÿÿ| * 000005e0 ff 7f ff ff ff 7f ff ff ff 7f ff ff ff 00 00 00 |ÿ.ÿÿÿ.ÿÿÿ.ÿÿÿ...| 000005f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Seen in the classified ads: COMPLETE SET OF ENCYCLOPEDIA BRITANNICA. 45 VOLUMES. EXCELLENT CONDITION. $1000 OR BEST OFFER. NO LONGER NEEDED. MARRIED. WIFE KNOWS EVERYTHING. |
From: Michael R. <mr...@us...> - 2003-12-28 16:26:46
Attachments:
dump-nav.patch
|
Hi, > > So somehow sector 0 is supposed to be a NAV packet, but > > libdvdnav says it is not. I would like to see a copy of this NAV > > packet. I think you can obtain it by mounting the disc and typing > > > > dd if=/mnt/dvd/VIDEO_TS/VTS_01_1.VOB bs=2048 count=1 > NAV > > First 2048 bytes of vts_01_1.vob attached in a file called NAV. That's a valid NAV packet. So most likely dvdnav reads something else. One thing you could test easily: Try deactivating the read cache (config entry input.dvd_use_readahead). If that is not the cause, here is another patch which will dump the failing packet to disc. (The file will be called "NAV" as well, so remove any previous ones, just to make sure.) Michael -- panic("Aarggh: attempting to free lock with active wait queue - shoot Andy"); 2.0.38 /usr/src/linux/fs/locks.c |
From: Godwin S. <gst...@sp...> - 2003-12-28 17:07:34
Attachments:
NAV
|
Sun, 28 Dec 2003 17:26:37 +0100 scripsit Michael Roitzsch: > That's a valid NAV packet. So most likely dvdnav reads something else. > One thing you could test easily: Try deactivating the read cache > (config entry input.dvd_use_readahead). Tried that - it didn't work :( > If that is not the cause, here is another patch which will dump the > failing packet to disc. (The file will be called "NAV" as well, so remove > any previous ones, just to make sure.) The file is attached, and here's a hexdump of it, the data is totally different: $ hexdump -C NAV 00000000 00 88 55 41 01 00 00 00 00 00 00 00 fc f1 0a 40 |..UA........üñ.@| 00000010 00 00 00 00 90 14 6b 08 58 41 08 40 c4 93 6a 08 |......k.XA.@Ä.j.| 00000020 c6 3f 08 40 f0 14 6b 08 c4 93 6a 08 00 00 00 00 |Æ?.@ð.k.Ä.j.....| 00000030 00 00 00 00 38 6d 69 08 b8 e8 80 08 99 a2 c3 40 |....8mi.žè...¢Ã@| 00000040 08 e0 78 42 a0 79 69 08 00 08 00 00 00 00 00 00 |.àxB yi.........| 00000050 50 76 69 08 50 76 69 08 a0 28 6a 08 b8 e8 80 08 |Pvi.Pvi. (j.žè..| 00000060 00 00 00 00 38 6d 69 08 50 76 69 08 f3 9b c3 40 |....8mi.Pvi.ó.Ã@| 00000070 b8 e8 80 08 00 00 00 00 fc f1 0a 40 2d 7b 09 40 |žè......üñ.@-{.@| 00000080 b8 e8 80 08 00 00 00 00 a8 7b 12 40 e0 fb df bd |žè......š{.@àûßœ| 00000090 00 00 00 00 d4 fb df bd 63 c4 11 40 38 6d 69 08 |....ÔûßœcÄ.@8mi.| 000000a0 74 fc df bd 00 00 00 00 00 00 00 00 00 00 00 00 |tüßœ............| 000000b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000160 00 00 00 00 00 00 00 00 70 c3 11 40 00 00 00 00 |........pÃ.@....| 00000170 00 00 00 00 00 00 00 00 64 ad 4a 40 e0 fb df bd |........dJ@àûßœ| 00000180 e0 fb df bd 00 00 00 00 e0 fb df bd 00 00 00 00 |àûßœ....àûßœ....| 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000001c0 e0 fb ff bd e0 50 12 40 00 00 00 00 00 00 00 00 |àûÿœàP.@........| 000001d0 0f 80 05 00 9d 3b 00 00 00 00 00 00 90 7f 12 40 |.....;.........@| 000001e0 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ...............| 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000200 00 01 00 00 00 00 00 00 00 00 00 00 2c 7a 09 40 |............,z.@| 00000210 38 6d 69 08 00 20 00 80 00 00 00 00 00 00 00 00 |8mi.. ..........| 00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000230 00 00 00 00 5e 13 12 40 9a 09 c5 40 08 e0 78 42 |....^..@..Å@.àxB| 00000240 00 00 00 00 de 16 12 40 00 00 00 00 5e 13 12 40 |....Þ..@....^..@| 00000250 10 fd 12 08 38 6d 69 08 00 00 00 00 08 e0 78 42 |.ý..8mi......àxB| 00000260 00 00 00 00 00 00 00 00 00 00 00 00 5e 13 12 40 |............^..@| 00000270 00 00 00 00 a8 7b 12 40 00 00 00 00 de 16 12 40 |....š{.@....Þ..@| 00000280 18 9c ff bf 5e d7 11 40 28 99 16 08 a8 7b 12 40 |..ÿ¿^×.@(...š{.@| 00000290 38 6d 69 08 ff ff ff ff 00 00 00 00 00 00 00 00 |8mi.ÿÿÿÿ........| 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 c3 4f 40 |.............ÃO@| 00000320 00 00 00 00 00 00 00 00 60 7a 4f 40 80 75 4e 40 |........`zO@.uN@| 00000330 80 83 4e 40 80 7d 4e 40 9c fd df bd 04 00 00 00 |..N@.}N@.ýßœ....| 00000340 a4 fd df bd 00 00 00 00 ac fd df bd 00 00 00 00 |€ýßœ....¬ýßœ....| 00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000550 00 00 c0 bd 00 10 00 00 0f 00 00 00 00 00 00 00 |..Àœ............| 00000560 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000570 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 |................| 00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000590 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000005a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000800 -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Mary had a little lamb which walked into a pylon Ten thousand volts went up its @$$ and turned its fleece to nylon |
From: Godwin S. <gst...@sp...> - 2003-12-28 18:04:22
|
Sun, 28 Dec 2003 17:26:37 +0100 scripsit Michael Roitzsch: > That's a valid NAV packet. So most likely dvdnav reads something else. I also added a bit more debugging output in case it helps: dvdnav.c: dvdnav_decode_packet() failed: this->path = /dev/dvd dvdnav.c: dvdnav_decode_packet() failed: this->open_vtsN = -1 dvdnav.c: dvdnav_decode_packet() failed: this->open_domain = -1 dvdnav.c: dvdnav_decode_packet() failed: this->err_str = New position not yet determined. This is output immediately after the current packet is dumped into NAV. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Nine megs for the secretaries fair, Seven megs for the hackers scarce, Five megs for the grads in smoky lairs, Three megs for system source. One disk to rule them all, One disk to bind them, One disk to hold all the files, And in the darkness grind 'em. |
From: Michael R. <mr...@us...> - 2003-12-28 18:05:11
|
Hi, > > That's a valid NAV packet. So most likely dvdnav reads something > > else. One thing you could test easily: Try deactivating the read > > cache (config entry input.dvd_use_readahead). > > Tried that - it didn't work :( At least that means my cache code is not at fault... :) > > If that is not the cause, here is another patch which will dump the > > failing packet to disc. (The file will be called "NAV" as well, so > > remove any previous ones, just to make sure.) > > The file is attached, and here's a hexdump of it, the data is totally > different: Looks like libdvdread is reading something wrong. Do you see a way of finding out from where in which file this sector actually comes from? Michael -- "Order is for the simple-minded - it's the genius who rules the chaos." -Sir Arthur Conan Doyle |
From: Godwin S. <gst...@sp...> - 2003-12-29 14:32:11
|
Sun, 28 Dec 2003 19:05:03 +0100 scripsit Michael Roitzsch: > Looks like libdvdread is reading something wrong. Do you see a way of > finding out from where in which file this sector actually comes from? This data pattern appears in *NONE* of the files (.vob, .ifo or .bup) on the DVD. Could it be that the .vob files need descrambling before searching through them for this data? If so, how do I go about that on a command line? -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Do molecular biologists wear designer genes? |
From: Michael R. <mr...@us...> - 2003-12-28 18:09:48
|
Hi, > I also added a bit more debugging output in case it helps: > > dvdnav.c: dvdnav_decode_packet() failed: this->path = /dev/dvd > dvdnav.c: dvdnav_decode_packet() failed: this->open_vtsN = -1 > dvdnav.c: dvdnav_decode_packet() failed: this->open_domain = -1 Thanks for this, I think you found something: These two -1 look strange, I suspect they are wrong. I will look through some code and get back on this tomorrow. Michael -- panic("aha1740.c"); /* Goodbye */ 2.2.16 /usr/src/linux/drivers/scsi/aha1740.c |
From: Godwin S. <gst...@sp...> - 2003-12-28 18:21:58
|
Sun, 28 Dec 2003 19:09:39 +0100 scripsit Michael Roitzsch: > These two -1 look strange, I suspect they are wrong. I will look through > some code and get back on this tomorrow. Thanks for the time you're putting into it for ONE disc which refuses to play! I also have another query but I've tagged it onto the relevent thread. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Are Linux users lemmings collectively jumping off of the cliff of reliable, well-engineered commercial software? -- Matt Welsh |
From: Michael R. <mr...@us...> - 2003-12-29 16:30:53
|
Hi again, > > These two -1 look strange, I suspect they are wrong. I will look > > through some code and get back on this tomorrow. > > Thanks for the time you're putting into it for ONE disc which refuses > to play! Every single DVD gets us closer to 100%. :) But those suspicious -1 are not wrong at all, you just found out that the two members open_vtsN and open_domain are not really used anywhere in libdvdnav. So the first result of this thread is saving 8 bytes of memory... Michael -- printk(KERN_WARNING "Multi-volume CD somehow got mounted.\n"); 2.2.16 /usr/src/linux/fs/isofs/inode.c |
From: Michael R. <mr...@us...> - 2003-12-29 16:30:51
|
Hi, > > Looks like libdvdread is reading something wrong. Do you see a way > > of finding out from where in which file this sector actually comes > > from? > > This data pattern appears in *NONE* of the files (.vob, .ifo or .bup) > on the DVD. > > Could it be that the .vob files need descrambling before searching > through them for this data? If so, how do I go about that on a > command line? That's true, if the disc is encrypted, you won't find this block anywhere. My guess is now that we are seeing a bug in libdvdread. Could you try copying the files to harddisk and play them from there? libdvdcss should do the decryption on-the-fly. This will use a different filesystem backend in libdvdread. Michael -- prom_printf("Detected PenguinPages, getting out of here.\n"); 2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c |
From: Godwin S. <gst...@sp...> - 2003-12-29 16:05:59
|
Mon, 29 Dec 2003 16:44:03 +0100 scripsit Michael Roitzsch: > My guess is now that we are seeing a bug in libdvdread. Could you try > copying the files to harddisk and play them from there? libdvdcss > should do the decryption on-the-fly. This will use a different > filesystem backend in libdvdread. Tell me if I got this right: I set input.dvd_device to /home/godwin/dvd_test, and that path contains the contents of the VIDEO_TS directory on the DVD (i.e. all the .VOB, .IFO and .BUP files). That would appear to be correct since playback of the DVD worked as usual, except that.... When you get to the area where the movie itself is supposed to start, the disk starts thrashing, xine is using up 70% CPU cycles. -- G. Stewart -- gst...@bo... -- gst...@sp... Registered Linux user #284683 (Slackware 9.0, Linux 2.4.23) -------------------------------------------------------------- Cat, n: Lapwarmer with built-in buzzer. |
From: Michael R. <mr...@us...> - 2003-12-29 16:34:26
|
Hi, > > My guess is now that we are seeing a bug in libdvdread. Could you > > try copying the files to harddisk and play them from there? > > libdvdcss should do the decryption on-the-fly. This will use a > > different filesystem backend in libdvdread. > > Tell me if I got this right: > > I set input.dvd_device to /home/godwin/dvd_test, and that path > contains the contents of the VIDEO_TS directory on the DVD (i.e. all > the .VOB, .IFO and .BUP files). That's possible. You can also leave input.dvd_device as it is and launch xine with "xine dvd:/home/godwin/dvd_test/" (the trailing slash is important). > That would appear to be correct since playback of the DVD worked as > usual, except that.... > > When you get to the area where the movie itself is supposed to start, > the disk starts thrashing, xine is using up 70% CPU cycles. Is that the place where playing from DVD directly stops? Michael -- WARNING: REALITY.SYS has been corrupted. Reboot universe? (y/n/a) |