VidMGR

[lrhorer]

Originally Posted by wmcbrine

No. It has nothing at all to do with the MOOV atom. MOOV atoms don't even exist in MKV containers, only in MP4 and MOV containers (MP4 is a variant of MOV). The MOOV problem is fully handled by qt-faststart. It does not enter into remuxing, and ffmpeg is not involved.

Oh, OK. I thought MKV was also a variant of MOV. Obviously I don't know much about the MKV container, but that is not surprising since I have never dealt with an MKV container.

[lrhorer]

Originally Posted by wmcbrine

The NPL is the main interface to pyTivo. All this push stuff is an add-on.

Well, this is the vidmgr thread.

Originally Posted by wmcbrine

Just go down to the bottom of the Now Playing list (or "My Shows" in the HDUI).

Hmm. Are you saying on your Premier, the list is still named NPL in the SDUI? On the CATV leased Premier my new CATV provider just gave me, it is "My Shows" in both the SDUI and the HDUI.

Originally Posted by wmcbrine

You should see your share name(s) there. Select one. Pick a program. Transfer it.

Perhaps a little clarification is in order.

If one is going to recode, anyway, and one is going to mostly pull videos from the server using the NPL / My Shows screen, it may well be best to code the videos as MPEG-II (.mpg). This will result in the fastest transcode or no recode at all when transferring using the pull method. If one intends to transfer using primarily a push method, either from the pyTivo web interface or via vidmgr (or via any other method - I often use curl), then MPEG-II is still a fairly good choice for many situations.

The other good choice is to recode to h.264 in a .mp4 container. There are a few disadvantages, especially if the audio is not AC3, or especially if the user chooses to transfer via pull. AAC audio cannot be handled properly by the TiVo, and a pull cannot handle h.264, necessitating a recode by pyTivo via ffmpeg, which rather defeats the main purpose of recoding to h.264 in the first place.

Bearing those caveats in mind, h.264 coding is more compact than MPEG-II coding for the same PQ. In the case of the default h.264 profiles in VRD, smaller by about 30%. That means one can store almost 1/3 more video in the same space if one employs h.264 coding. Not only that, but h.264 files pushed to the TiVo transfer much, much faster than MPEG-II files. On the Premier, almost a factor of 2, or roughly 15X real-time for 1080i content. On the S3, a factor of more than 3, especially with 720p content. On the THD it transfers beter than 4 times faster than the same 720p content coded as MPEG-II.

[markmarz]

Originally Posted by lrhorer

I suggest you try this: ...

Sorry, didn't see your response till just now. Thought I had monitoring on this thread ..

Anyway, I wound up reinstalling Debian on my server for a completely unrelated set of reasons. Now this strangeness has disappeared. But thanks the same!

[markmarz]

Originally Posted by lrhorer

Bearing those caveats in mind, h.264 coding is more compact than MPEG-II coding for the same PQ. In the case of the default h.264 profiles in VRD, smaller by about 30%.

Just one question about this .. if it needs more than one reply, I'll open a new thread in some other forum. If you're not using the default h.264 profile .. and maybe you are .. could you share your tweaked profile here? There's a million opinions in a thousand thickets and brambles. Yours I value from experience.

This is tangentially related to the thread, since it's in the context of fast pushes via vidmgr. But I won't press that.

[lrhorer]

Originally Posted by markmarz

Sorry, didn't see your response till just now. Thought I had monitoring on this thread ..

Anyway, I wound up reinstalling Debian on my server for a completely unrelated set of reasons. Now this strangeness has disappeared. But thanks the same!

It is very rare that a Linux system ever actually requires a full re-install. Finding and stamping out problems is a breeze compared with certain other operating systems. In the worst case, one can do a distro download to a temporary directory and pick out files to overwrite the damaged area(s), even if the damage is to the kernel. This allows one to keep one's configurations and all installed applications without having to re-install or re-configure everything. More often than not, however, one can simply fix a config file, a damaged script, or simply issue an apt-get remove xxxx followed by an apt-get install xxxx. For Debian based distros, that is. Red Hat based distros are a little bit different, but a similar approach applies.

Originally Posted by markmarz

Just one question about this .. if it needs more than one reply, I'll open a new thread in some other forum.

Actually, I think maybe I will start a Linux support thread over in the main Home Media / TTG forum. The number of Linux users is not vast, but the topics are detailed enough to warrant it, I think.

Originally Posted by markmarz

If you're not using the default h.264 profile .. and maybe you are .. could you share your tweaked profile here?

Well, there is more than one h.264 profile. You want the h.264 - MP4 profile as you can see here

As far as tweaks are concerned, I only implemented a small handful. I don't recall if the "Move MOOV atom to start of file" check box was checked by default, or not, but if not, it definitely needs to be checked. This slows down processing a huge amount, but it is absolutely necessary for natively pushing to a TiVo.

The second was the "MP4 temporary file location override". This is not essential, but it recovers some of the speed lost by forcing the MOOV atom to be written to the beginning of the file if one points this to a directory on the local hard drive when the target file is on the LAN, assuming you have a fairly decent local hard drive. This is under Tools => Options => H.264 Options.

Under Manual Parameter Setings ( Tools => <Shift>+Options ), I did change the default log file viewer (because I detest notepad.exe).

Also, I have found every once in a while VRD has problems with files that have errors in them (especially when pulled from a TiVo), and while Quick Stream Fix can take care of them, certain errors will not be caught if one leaves the "Ignore transport stream maps" check box checked, so I un-checked it. Note this should not be required if one is re-coding a raw file to h.264, but I always edit the files before re-coding them, and VRD occasionally chokes on a file unless I run QSF on it, first. In these cases, I run QSF and it invariably alleviates the issue, but again only if the default of ignoring the stream maps is disabled.

[markmarz]

Originally Posted by lrhorer

Actually, I think maybe I will start a Linux support thread over in the main Home Media / TTG forum. The number of Linux users is not vast, but the topics are detailed enough to warrant it, I think.

That's great! Looking forward to it.

And thanks for the h.264 info, very helpful.