Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
28th December 2013, 18:08 | #18681 | Link | |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Quote:
Last edited by Guest; 28th December 2013 at 18:16. |
|
28th December 2013, 20:05 | #18683 | Link | |
Aging Video Hobbyist
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
|
Quote:
Wondered if any other BD-RB'er regularly uses it sucessfully because I frankly don't use BD-RB very often, though I do use DGIndexNV.exe 64-bit regularly in my own custom .cmd files and it always performs flawlessly for me! So I think: the way it's called? A conflict with another running process? A glitch in the drive serving the .iso? VirtualCloneDrive? AnyDVDHD? My CPU or memory? Not likely to be a DG issue but thought I'd ask if others here use it regularly. A couple sample "corrupt" .DGI files I had the presence of mind to save: Code:
DGVC1IndexFileNV14 DGIndexNV 2046 X64 C:\Program Files (x86)\DGIndexNV\ V:\BDMV\STREAM\00011.m2ts 754575360 DEVICE 0 DECODE_MODES 0,1,0 STREAM 1 PKTSIZ 192 VPID 4113 CLIP 0 0 0 0 RANGE 0 0 754575359 0 AUDIO SEQ 798 1 1 0 5 ENTRY 823 0 64 0:FRM 0 0 2 1:FRM 3 0 2 2:FRM 1 0 2 3:FRM 3 0 2 4:FRM 1 0 2 5:FRM 3 0 2 6:FRM 1 0 2 7:FRM 3 0 2 8:FRM 1 0 2 9:FRM 1 0 2 10:FRM 3 0 2 11:FRM 1 0 2 12:FRM 3 0 2 13:FRM 1 0 2 SEQ 343902 1 1 0 5 ENTRY 343927 0 0 14:FRM 3 0 2 15:FRM 0 0 2 16:FRM 3 0 2 17:FRM 1 0 2 18:FRM 3 0 2 19:FRM 3 0 2 20:FRM 3 0 2 21:FRM 3 0 2 22:FRM 1 0 2 SEQ 2024478 1 1 0 5 ENTRY 2024503 0 0 23:FRM 3 0 2 24:FRM 0 0 2 25:FRM 3 0 2 26:FRM 3 0 2 27:FRM 1 0 2 28:FRM 3 0 2 29:FRM 1 0 2 30:FRM 1 0 2 31:FRM 3 0 2 32:FRM 1 0 2 33:FRM 1 0 2 34:FRM 3 0 2 35:FRM 1 0 2 36:FRM 3 0 2 37:FRM 1 0 2 38:FRM 3 0 2 39:FRM 1 0 2 40:FRM 1 0 2 41:FRM 3 0 2 42:FRM 1 0 2 43:FRM 3 0 2 44:FRM 1 0 2 45:FRM 3 0 2 46:FRM 1 0 2 47:FRM 3 0 2 48:FRM 3 0 2 49:FRM 1 0 2 50:FRM 3 0 2 51:FRM 1 0 2 52:FRM 1 0 2 SIZ 0 x 0 FPS 0 / 0 CODED 53 PLAYBACK 53 0.00% FILM ORDER 1 Code:
DGAVCIndexFileNV14 DGIndexNV 2046 X64 C:\Program Files (x86)\DGIndexNV\ V:\BDMV\STREAM\00029.m2ts 138829824 DEVICE 0 DECODE_MODES 0,1,0 STREAM 1 PKTSIZ 192 VPID 4113 CLIP 0 0 0 0 RANGE 0 0 138829823 0 AUDIO SIZ 0 x 0 FPS 0 / 0 CODED 0 PLAYBACK 0 0.00% FILM ORDER -1 |
|
28th December 2013, 20:13 | #18684 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Well the problem is obviously the size being set as 0 x 0 and FPS as 0 / 0. And the second one has no frames at all. I've never seen anything like this, either using DGIndexNV standalone or with MEGUI (I haven't used BDRB).
You'd have to find a repeatable case and provide the stream to allow me to diagnose it. Maybe others can comment on your suggested causes. EDIT: I can't even see a code path that would allow DGIndexNV to print 0 / 0 as the frame rate! So memory issues, etc., are possible. Last edited by Guest; 28th December 2013 at 20:23. |
28th December 2013, 21:10 | #18685 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
I deleted the .dgi, restarted the indexing and all went smooth. I didn't pay much attention to the incident as it has happened only once. Unfortunately I don't remember the source. If I can trace it back I could try to reproduce the case. |
|
28th December 2013, 21:43 | #18686 | Link | |
Aging Video Hobbyist
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
|
Quote:
And thank you too Sharc for chiming-in. I must say I impressed myself by finding why x264 choked. That the job merely resumes after letting DGIndexNV try again is a relief of course. Sorry for the distraction fellas--my money's on a weak eSATA link. |
|
28th December 2013, 21:51 | #18687 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
Run some good RAM checks also. I doubt the eSATA theory because I see only a memory corruption as a possibility. DGIndexNV reads the fps_num and fps_den from the stream. If either is seen as zero it changes it to 25fps. The only mechanism I can think of is that it reads the fps_num and fps_den correctly but then subsequently the memory gets trashed before the DGI is written.
Last edited by Guest; 28th December 2013 at 21:53. |
28th December 2013, 22:32 | #18689 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
|
|
28th December 2013, 22:35 | #18690 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
Having trouble in what way? I've never had an issue with DGIndexNV... |
|
28th December 2013, 23:35 | #18691 | Link | |
Registered User
Join Date: May 2006
Posts: 3,997
|
Quote:
Code:
MENU_BACKGROUND=C:\Program Files Video\BD_Rebuilder\misc\menuback.jpg IMPORT_THRESHOLD=6 QUICK_PLAY_THRESHOLD=6 MENU_AUTO_BACKGROUND=1 MENU_PLAY_SEQUENTIAL=0 MENU_START_WITH_MENU=1 |
|
28th December 2013, 23:42 | #18692 | Link | |
Aging Video Hobbyist
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
|
Quote:
I'm going to move my eSATA drive anyway and then I just might do the Memtest86+ and/or torture-test program whose name escapes me atm. |
|
29th December 2013, 16:23 | #18694 | Link |
Aging Video Hobbyist
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
|
Well I had been looking at this AUD_00011.meta file, which purports to demux the video, though now that I look again at the .DGI file it does refer instead to the original .m2ts on the disc (see .DGI above):
Code:
MUXOPT --no-pcr-on-video-pid --new-audio-pes --demux --vbr --vbv-len=500 V_MS/VFW/WVC1, "V:\BDMV\STREAM\00011.m2ts", fps=29.97, track=4113 A_AC3, "V:\BDMV\STREAM\00011.m2ts", track=4352, lang=eng S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4608,lang=jpn S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4609,lang=eng S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4610,lang=fra S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4611,lang=deu S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4612,lang=spa S_HDMV/PGS, "V:\BDMV\STREAM\00011.m2ts",fps=29.97, track=4613,lang=nld EDIT: OK I'm running it again and clearly tsMuxeR.exe is running to demux the audio (and the videotrack) while DGIndexNV is running simultaneously, apparently (to me anyway) to index the very same .m2ts being demuxed. I wouldn't have thought this was possible, that the m2ts would be locked by one process or the other, but I am not a programmer. Last edited by laserfan; 29th December 2013 at 16:57. |
29th December 2013, 17:11 | #18695 | Link |
Guest
Join Date: Jan 2002
Posts: 21,901
|
As you say it depends on whether the file is locked. But if you are just reading there is no need to lock it when opening it, and concurrent processes can read the same file. When writing a file you want exclusive access to avoid collisions.
|
29th December 2013, 17:59 | #18696 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
The file isn't locked... both processes are reading it simultaneously. That saves a lot of time because at any point one or the other is finding its records in cache rather than having to do a physical read. In most cases it takes about half as long as having to do each process sequentially. Last edited by jdobbs; 29th December 2013 at 18:05. |
|
29th December 2013, 18:24 | #18697 | Link |
Aging Video Hobbyist
Join Date: Dec 2004
Location: Off the Map
Posts: 2,461
|
Ok I didn't know if this was possible; only thinking maybe 64-bit DGIndexNV might be too "quick on the draw" for tsMuxeR or something. That's a technical term...
Thanks for the explanations fellas. I had thought about "demux the video in case you use it as-is" but it's nice to get confirmation about that too J. |
29th December 2013, 18:50 | #18698 | Link | |
Moderator
Join Date: Oct 2001
Posts: 20,973
|
Quote:
It's possible the two apps may get out-of-sync in their reading, but that's rare. Generally the app that is behind in reading catches up because its data is cached, and it may even become the leader -- causing the other app to be cached and catch up. They may change positions several times during execution -- but most of the time they finish within a second of each other. Last edited by jdobbs; 29th December 2013 at 18:56. |
|
30th December 2013, 05:21 | #18699 | Link |
Registered User
Join Date: Oct 2010
Posts: 232
|
Hi @jdobbs
You know i do not how to do with bd rebuilder, what options to use, I have some movies on Bluray discs and need to pass them directly to mkv format with no loss of both audio and video and subtitles , that is, all intact. I tried eg MakeMKV but give me a problem and I try to Bd rebuilder but it insists to make a "reencoding". There is an option of passing directly without "touching" audio and video and subs? Thanks for your time! sorry to bother you, I had not seen the option to intact audio / video Thanks again Last edited by Blurayhd; 30th December 2013 at 05:52. |
30th December 2013, 07:19 | #18700 | Link | |
Registered User
Join Date: Apr 2003
Location: Within the main Source.
Posts: 895
|
Quote:
From BD-RB Menu select Mode. Movie-Only Backup. Alternate Movie-Only Output. It's in the list.
__________________
Life is not a journey to the grave; but rather to skid out broadside, thoroughly used, torn and warn and loudly proclaim; WOW; What a ride!!! Soon, I'm going to do it AGAiN in different skin!! Last edited by AmigaFuture; 30th December 2013 at 07:50. Reason: Joined posts. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|