dvdread patch for broken dvd's
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread. Any comments are welcome. I will be glad if this commit will be accepted to libdvdread. Regards -- Jezz mail: jezz@hkfree.org jabber: jezz@njs.netlab.cz
Il giorno dom, 05/10/2008 alle 16.56 +0200, jezz@hkfree.org ha scritto:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Any comments are welcome. I will be glad if this commit will be accepted to libdvdread.
Regards
thanks, but there are several problems: - it's full of cosmetics - I don't see how you handle the 262<->261 code - are you sure that all of is09660.c is necessary?
Il giorno dom, 05/10/2008 alle 22.12 +0200, Nico Sabbi ha scritto:
Il giorno dom, 05/10/2008 alle 16.56 +0200, jezz@hkfree.org ha scritto:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Any comments are welcome. I will be glad if this commit will be accepted to libdvdread.
Regards
thanks, but there are several problems: - it's full of cosmetics - I don't see how you handle the 262<->261 code - are you sure that all of is09660.c is necessary?
one more question: are the specs available here complete? http://osta.org/specs/index.htm Just searching the table of Tag identifiers I can't find it. It seems that only items in [bold] are specified. Am I missing something? There are referenced to ECMA 167, is that pdf a complementary document?
Il giorno dom, 05/10/2008 alle 22.25 +0200, Nico Sabbi ha scritto:
Il giorno dom, 05/10/2008 alle 22.12 +0200, Nico Sabbi ha scritto:
Il giorno dom, 05/10/2008 alle 16.56 +0200, jezz@hkfree.org ha scritto:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Any comments are welcome. I will be glad if this commit will be accepted to libdvdread.
Regards
thanks, but there are several problems: - it's full of cosmetics - I don't see how you handle the 262<->261 code - are you sure that all of is09660.c is necessary?
one more question: are the specs available here complete? http://osta.org/specs/index.htm
Just searching the table of Tag identifiers I can't find it. It seems that only items in [bold] are specified. Am I missing something? There are referenced to ECMA 167, is that pdf a complementary document?
apparently yes, here is what you need :) http://www.ecma-international.org/publications/standards/Ecma-167.htm
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too. On Ne 5.říj, Nico Sabbi wrote:
Il giorno dom, 05/10/2008 alle 22.25 +0200, Nico Sabbi ha scritto:
Il giorno dom, 05/10/2008 alle 22.12 +0200, Nico Sabbi ha scritto:
Il giorno dom, 05/10/2008 alle 16.56 +0200, jezz@hkfree.org ha scritto:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Any comments are welcome. I will be glad if this commit will be accepted to libdvdread.
Regards
thanks, but there are several problems: - it's full of cosmetics - I don't see how you handle the 262<->261 code - are you sure that all of is09660.c is necessary?
one more question: are the specs available here complete? http://osta.org/specs/index.htm
Just searching the table of Tag identifiers I can't find it. It seems that only items in [bold] are specified. Am I missing something? There are referenced to ECMA 167, is that pdf a complementary document?
apparently yes, here is what you need :) http://www.ecma-international.org/publications/standards/Ecma-167.htm
-- Jezz mail: jezz@hkfree.org jabber: jezz@njs.netlab.cz
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
On Út 7.říj, Nico Sabbi wrote:
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
The ISO part is programmed using this documentation: http://alumnus.caltech.edu/~pje/iso9660.html I suppose, that simplified ISO spec is sufficient for DVD video. Moreover this is only fallback method. Is there any coding style for dvdnav/dvdread sources? May be GNU indent will fix this :). Or did you mean something different as cosmetics? -- Jezz mail: jezz@hkfree.org jabber: jezz@njs.netlab.cz
Il giorno mer, 08/10/2008 alle 21.10 +0200, jezz@hkfree.org ha scritto:
On Út 7.říj, Nico Sabbi wrote:
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
The ISO part is programmed using this documentation: http://alumnus.caltech.edu/~pje/iso9660.html I suppose, that simplified ISO spec is sufficient for DVD video. Moreover this is only fallback method.
Is there any coding style for dvdnav/dvdread sources? May be GNU indent will fix this :). Or did you mean something different as cosmetics?
cosmetics are non-semantic changes; they are fine as long as they are isolated from semantic changes and as long as they don't change the style of the enclosing files
On St 8.říj, Nico Sabbi wrote:
Il giorno mer, 08/10/2008 alle 21.10 +0200, jezz@hkfree.org ha scritto:
On Út 7.říj, Nico Sabbi wrote:
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
The ISO part is programmed using this documentation: http://alumnus.caltech.edu/~pje/iso9660.html I suppose, that simplified ISO spec is sufficient for DVD video. Moreover this is only fallback method.
Is there any coding style for dvdnav/dvdread sources? May be GNU indent will fix this :). Or did you mean something different as cosmetics?
cosmetics are non-semantic changes; they are fine as long as they are isolated from semantic changes and as long as they don't change the style of the enclosing files
Hi, I have sent patch to this list before a long time. I don't know what I should do to see this patch applied. I doubt, that I have rights to send something to dvdnav/dvdread subversion repository. Are there any pending changes, that must be applied before anything else? Is there something I can help with? Regards Jezz
Il giorno dom, 23/11/2008 alle 15.15 +0100, jezz@hkfree.org ha scritto:
On St 8.říj, Nico Sabbi wrote:
Il giorno mer, 08/10/2008 alle 21.10 +0200, jezz@hkfree.org ha scritto:
On Út 7.říj, Nico Sabbi wrote:
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
The ISO part is programmed using this documentation: http://alumnus.caltech.edu/~pje/iso9660.html I suppose, that simplified ISO spec is sufficient for DVD video. Moreover this is only fallback method.
Is there any coding style for dvdnav/dvdread sources? May be GNU indent will fix this :). Or did you mean something different as cosmetics?
cosmetics are non-semantic changes; they are fine as long as they are isolated from semantic changes and as long as they don't change the style of the enclosing files
Hi, I have sent patch to this list before a long time. I don't know what I should do to see this patch applied. I doubt, that I have rights to send something to dvdnav/dvdread subversion repository. Are there any pending changes, that must be applied before anything else? Is there something I can help with?
Regards Jezz
Hi, there weren't substantial changes to the repository, your patches still apply. I'm very sorry, but they are still pending. I didn't forget about them but I haven't had enough time to review them completely. Please, have patience: I'm very busy with daily work and personal problems in this period, and a bit weak, too. I'll apply them as soon as I find some more time. Nico
On Ne 23.lis, Nico Sabbi wrote:
Il giorno dom, 23/11/2008 alle 15.15 +0100, jezz@hkfree.org ha scritto:
On St 8.říj, Nico Sabbi wrote:
Il giorno mer, 08/10/2008 alle 21.10 +0200, jezz@hkfree.org ha scritto:
On Út 7.říj, Nico Sabbi wrote:
Il giorno lun, 06/10/2008 alle 22.09 +0200, jezz@hkfree.org ha scritto:
Hi, here are my answers. Cosmetics are not problem, but before fixing them, the idea of this code must be approved. For file there are 2 possible tag values - 261 for File Entry (4/14.9 in Ecma 167) or Extended File Entry (4/14.17). For some VOBS on DVD there is no File Entry or Extended File Entry. But there is Extended Attribute Header Entry with tag 262 (4/14.10). If I handle 262 entry as 261, than DVD plays fine, but that is wrong - EA Header is not File Entry + some data. It contains data associated with some File Entry, but there is none. Therefor this DVD is broken. But ISO 9660 filesystem is ok - kernel mounts this DVD and totem can play it (totem don't plays discs directly, but only mounted). I can play VOB directly using mplayer, but I can't use dvdnav or some mplayer front-ends. This ISO stuff uses correct ISO fs if file search on UDF fails. This fixes my problem - and maybe others, too.
I agree completely with your method: accepting tag 262 as valid is plain wrong, and for the rest (without reading the code of iso9660) the code is fine Please, don't top post in mplayerhq mailing lists
The ISO part is programmed using this documentation: http://alumnus.caltech.edu/~pje/iso9660.html I suppose, that simplified ISO spec is sufficient for DVD video. Moreover this is only fallback method.
Is there any coding style for dvdnav/dvdread sources? May be GNU indent will fix this :). Or did you mean something different as cosmetics?
cosmetics are non-semantic changes; they are fine as long as they are isolated from semantic changes and as long as they don't change the style of the enclosing files
Hi, I have sent patch to this list before a long time. I don't know what I should do to see this patch applied. I doubt, that I have rights to send something to dvdnav/dvdread subversion repository. Are there any pending changes, that must be applied before anything else? Is there something I can help with?
Regards Jezz
Hi, there weren't substantial changes to the repository, your patches still apply. I'm very sorry, but they are still pending. I didn't forget about them but I haven't had enough time to review them completely. Please, have patience: I'm very busy with daily work and personal problems in this period, and a bit weak, too. I'll apply them as soon as I find some more time.
Nico
Hi, first of all thanks for your quick answer. I just want to know current status. There is no need for hurry. I appreciate your and all mplayer developers' work. Best wishes Jezz
jezz@hkfree.org wrote:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Quite a different route. But yes, you need ExtFinfo support. It is very similar to Finfo, but pushes the record along somewhat. http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr... Don't forget to handle the chains of ADs, instead of just the one like dvdread assumes (which is probably ok for 99% of DVD images though). I did that by making a FileAD (instead of over-loading AD like they did, and fitting filesize 64bit into AD length 32 bit.) http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr... (Anyone know what the maximum number of AD chains there can be? ECMA did not specify). You probably also want to handle filetype 250, which appears to be a re-direct type block. It will enable you to read UDF2.50. Lund -- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
Hi, I think, that my problem is different. I have only 261 & 262 entries. Neither 266 nor 250 are present. As workaround I propose to use ISO 9660 filesystem as fallback if UDF access fails. On Po 6.říj, Jorgen Lundman wrote:
jezz@hkfree.org wrote:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Quite a different route. But yes, you need ExtFinfo support. It is very similar to Finfo, but pushes the record along somewhat.
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr...
Don't forget to handle the chains of ADs, instead of just the one like dvdread assumes (which is probably ok for 99% of DVD images though). I did that by making a FileAD (instead of over-loading AD like they did, and fitting filesize 64bit into AD length 32 bit.)
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr... (Anyone know what the maximum number of AD chains there can be? ECMA did not specify).
You probably also want to handle filetype 250, which appears to be a re-direct type block. It will enable you to read UDF2.50.
Lund
-- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ DVDnav-discuss mailing list DVDnav-discuss@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
-- Jezz mail: jezz@hkfree.org jabber: jezz@njs.netlab.cz
Ah yes, I see now. You and I weren't talking about the same things. Ignore me. 261 (File info) and 262 (Extended Attribute Header) seems somewhat valid. Lund ps. Not related, but FileType 250 (In the user defined range) is a ExtFileInfo (266) Tag with filetype set to 250. Not TagID 250. pps. There are more bugs in opening a path to "VIDEO_TS", even after putting in dvdread-1.9.7's DVDOpenPath(). ppps. I did reverse quoting here, my apologies. My habit, sucks to have to scroll past old content when reading over VNC. :) jezz@hkfree.org wrote:
Hi, I think, that my problem is different. I have only 261 & 262 entries. Neither 266 nor 250 are present. As workaround I propose to use ISO 9660 filesystem as fallback if UDF access fails.
On Po 6.říj, Jorgen Lundman wrote:
jezz@hkfree.org wrote:
Hi, I have already posted this to mplayer-users mailing list. I have DVD disc with broken UDF structure. I can't play this disc using current libdvdread, because vob for chapter 37 is not found - entry in UDF has tag identifier 262 (Extended Attribute Header Descriptor) instead of 261 (File Entry). ISO 9660 filesystem is correct, so it can be used. When file can't be located with UDF functions, then we can try ISO. This fix conforms with standards and plays my disks :) Patch is created against current svn://svn.mplayerhq.hu/dvdnav/trunk/libdvdread.
Quite a different route. But yes, you need ExtFinfo support. It is very similar to Finfo, but pushes the record along somewhat.
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr...
Don't forget to handle the chains of ADs, instead of just the one like dvdread assumes (which is probably ok for 99% of DVD images though). I did that by making a FileAD (instead of over-loading AD like they did, and fitting filesize 64bit into AD length 32 bit.)
http://www.lundman.net/cvs/viewvc.cgi/lundman/llink/libdvdnav-4.1.2/src/dvdr... (Anyone know what the maximum number of AD chains there can be? ECMA did not specify).
You probably also want to handle filetype 250, which appears to be a re-direct type block. It will enable you to read UDF2.50.
Lund
-- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) _______________________________________________ DVDnav-discuss mailing list DVDnav-discuss@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
------------------------------------------------------------------------
_______________________________________________ DVDnav-discuss mailing list DVDnav-discuss@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
-- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
On Wednesday, 08 October 2008 at 02:16, Jorgen Lundman wrote: [...]
pps. There are more bugs in opening a path to "VIDEO_TS", even after putting in dvdread-1.9.7's DVDOpenPath().
Patches welcome. ;) And I think you meant 0.9.7, not 1.9.7.
ppps. I did reverse quoting here, my apologies. My habit, sucks to have to scroll past old content when reading over VNC. :)
You wouldn't have to scroll past it if you just trimmed the irrelevant quotes. Besides, mutt over ssh is faster. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
Dominik 'Rathann' Mierzejewski wrote:
pps. There are more bugs in opening a path to "VIDEO_TS", even after putting in dvdread-1.9.7's DVDOpenPath().
Patches welcome. ;)
And I think you meant 0.9.7, not 1.9.7.
Yes, that is correct. I have not had time to look a this. With libdvdnav version it just fails to open. With 0.9.7 version, it opens and works, but my rmem goes from normal 500k to 22M. I will have to go deeper. But I did send a patch, as it occurred to me that my job will possibly be easier in future when I need to upgrade my libdvdnav. I was bigger than the approved 40kb though.
You wouldn't have to scroll past it if you just trimmed the irrelevant quotes. Besides, mutt over ssh is faster.
Heh, mutt. Ahh I remember the 90s ;) But I still use it sometimes, if I only have screen. Lund -- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
Dominik 'Rathann' Mierzejewski wrote:
Patches welcome. ;)
[quote] "Your mail to 'DVDnav-discuss' with the subject [PATCH] UDF2.50 Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 50828 bytes with a limit of 40 KB" [/quote] You don't have to approve the patch, but let the email through at least :) Lund -- Jorgen Lundman | <lundman@lundman.net> Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home)
participants (4)
-
Dominik 'Rathann' Mierzejewski -
jezz＠hkfree.org -
Jorgen Lundman -
Nico Sabbi