1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

VidMGR

Discussion in 'Developers Corner' started by Soapm, Jan 8, 2012.

  1. techguy82

    techguy82 New Member

    11
    0
    Jun 23, 2012
    I just saved my file to MP4 with video redo(thanks by the way for that). I tried to send to tivo again and i got the same message. This time there was no ffmpep transcoding so that is good, but i got the same error message.

    Attached is a screenshot.

    Let me know if there is something i am missing

    Thanks
     

    Attached Files:

  2. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    Your screen shot is illegible.
     
  3. techguy82

    techguy82 New Member

    11
    0
    Jun 23, 2012
    Sorry about that, see attachment
     

    Attached Files:

  4. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    OK, thanks, but there's no new information in this screen shot.* Did you read my post #80?

    * Also, it's still barely legible. You should stop resizing them, and use PNG compression instead of JPG. (Of course for something like this, it would be even better to just copy and paste it as text.)
     
  5. techguy82

    techguy82 New Member

    11
    0
    Jun 23, 2012
    Thanks wmcbrine for your help.


    When you say "The solution is just to do a straight pull of the file from the NPL, which will force it to be transcoded to MPEG-2. This very rarely fails"

    how would i do this?

    i used makemkv for blu-ray to make these files into mkv. then used videredo to save them as mp4

    when i try to send to tivo i get the message below:



    INFO:pyTivo.video.video:[28/Jun/2012 21:39:04] Queued "\\Mybooklive\public\Blu-R
    ay Movies\BluRay MKVs\Sherlock Holmes A Game of Shadows (BluRay) (02).mp4" for P
    ush to DVR-0B92
    INFO:pyTivo:192.168.1.109 [28/Jun/2012 21:39:04] "POST /TivoConnect HTTP/1.0" 20
    0 -
    INFO:pyTivo:192.168.1.107 [28/Jun/2012 21:40:55] "GET /Blu-Ray/BluRay%20MKVs/She
    rlock%20Holmes%20A%20Game%20of%20Shadows%20(BluRay)%20(02).mp4?Format=video%2Fmp
    4 HTTP/1.1" 200 -
    INFO:pyTivo.video.video:[28/Jun/2012 21:40:55] Start sending "\\Mybooklive\publi
    c\Blu-Ray Movies\BluRay MKVs\Sherlock Holmes A Game of Shadows (BluRay) (02).mp4
    " to DVR-0B92
    INFO:pyTivo.video.video:[Errno 10054] An existing connection was forcibly closed
    by the remote host
    INFO:pyTivo.video.video:[Errno 10054] An existing connection was forcibly closed
    by the remote host
    INFO:pyTivo.video.video:[28/Jun/2012 21:40:57] Done sending "\\Mybooklive\public
    \Blu-Ray Movies\BluRay MKVs\Sherlock Holmes A Game of Shadows (BluRay) (02).mp4"
    to DVR-0B92, 0 bytes, 0.00 Mb/s
    ERROR:pyTivo:Exception during request from ('192.168.1.107', 41500)
    Traceback (most recent call last):
    File "C:\Python27\lib\SocketServer.py", line 582, in process_request_thread
    self.finish_request(request, client_address)
    File "C:\Python27\lib\SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
    File "C:\PyTivo\httpserver.py", line 85, in __init__
    client_address, server)
    File "C:\Python27\lib\SocketServer.py", line 640, in __init__
    self.finish()
    File "C:\Python27\lib\SocketServer.py", line 693, in finish
    self.wfile.flush()
    File "C:\Python27\lib\socket.py", line 303, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
    error: [Errno 10054] An existing connection was forcibly closed by the remote ho
    st
     
  6. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    The NPL is the main interface to pyTivo. All this push stuff is an add-on. Just go down to the bottom of the Now Playing list (or "My Shows" in the HDUI). You should see your share name(s) there. Select one. Pick a program. Transfer it.
     
  7. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    OK.

    Of course. If it were fully compatible, ffmpeg would never get called for the transfer. It of course does get called to identify the file's attributes prior to the transfer operation.

    OK. The point is, the remux is required because, among other things, the MOOV atom is in the wrong place, right? Or not?

    Well, yeah. This bit of the transaction has nothing to do with whether the file is remuxed, or not, AFAICT.

    Well, yes, except with that processor, the full recode to MPEG-II is liable to take quite a while, I think. Yes? I've never actually done a recode from h.264 to MPEG-II, but I did quite a large number of recodes from MPEG-II on a similar processor, and it took hours to recode a single movie. Even with a 3.0GHz, 6 core monster, it doesn't happen in real time. OTOH, perhaps recoding from h.264 to MPEG-II doesn't take as many resources. I don't really know for sure.

    Not so much. I've done thousands of recodes from MPEG-II to h.264 in .mp4. I just select a couple of hundred video files, start the VRD batch manager, and walk away. A week or so later, it's done. 'No trouble, at all, really.

    Howso? As I said, I've done a couple of thousand of them, and I continue to do three or four a day using VRD. I've never had one fail.

    Yeah, I thought I said that. Not in such detail, of course, but the point was the entire file has to be muxed in a temp file, the MOOV atom re-created, and then the entire thing has to be spooled back from the temp file to the final file, starting with the MOOV atom, because the TiVo won't accept a file with the MOOV atom at the end. Any edit to an H.264 file, BTW, requires the MOOV atom to be re-created, which means the temp file creation followed by a copy.
     
  8. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Amen.

    Or better yet, redirect stdout and stderr to a log file.
     
  9. wmcbrine

    wmcbrine Ziphead

    10,368
    22
    Aug 2, 2003
    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.
     
  10. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    What profile are you using? It should be h.264 in a .mp4 container:

    [​IMG]

    [​IMG]

    Or in the batch manager:

    [​IMG]

    Please use code tags around such dumps so instead of looking like the above, they look like:

    Code:
    INFO:pyTivo.video.video:[28/Jun/2012 21:39:04] Queued "\\Mybooklive\public\Blu-Ray Movies\BluRay MKVs\Sherlock Holmes A Game of Shadows (BluRay) (02).mp4" for Push to DVR-0B92
    INFO:pyTivo:192.168.1.109 [28/Jun/2012 21:39:04] "POST /TivoConnect HTTP/1.0" 200 -
    INFO:pyTivo:192.168.1.107 [28/Jun/2012 21:40:55] "GET /Blu-Ray/BluRay%20MKVs/Sherlock%20Holmes%20A%20Game%20of%20Shadows%20(BluRay)%20(02).mp4?Format=video%2Fmp4 HTTP/1.1" 200 -
     
  11. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    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.
     
  12. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    Well, this is the vidmgr thread.

    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.

    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.
     
  13. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    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!
     
  14. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    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.
     
  15. lrhorer

    lrhorer Active Member

    6,924
    0
    Aug 31, 2003
    San...
    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.

    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.

    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.
     
  16. markmarz

    markmarz Member

    94
    0
    Feb 3, 2002
    Chicago, IL
    That's great! Looking forward to it.

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

    djl25 C64 hacker

    95
    0
    May 26, 2005
    Providence, RI
    Hi all - I know I'm missing something obvious, but I cannot get vidmgr to run on my TivoHD. Using Version 0.7c with hme-python-0.20, I get:
    Code:
    192.168.1.15:35925 - - [26/Jun/2013 10:54:47] code 403, message Forbidden
    192.168.1.15:35925 - - [26/Jun/2013 10:54:47] "GET /picture/icon.png HTTP/1.0" 4
    03 -
    
    The picture viewer app runs fine, btw. How do I go about troubleshooting this?
     

Share This Page