pyTivo - Transcoding server

Discussion in 'TiVo Home Media Features & TiVoToGo' started by armooo, Nov 25, 2006.

  1. wmcbrine

    wmcbrine Well-Known Mumbler

    11,499
    701
    Aug 2, 2003
    If they pulled OK before you upgraded pyTivo, and not now, then I assume that pyTivo is now passing them through as OK, but the TiVo is choking on them. Try marking the container as bad in the metadata, so that pyTivo will remux them -- add a line like "Override_container: foo".

    The push issue just sounds like the typical flakiness from the mind server, unrelated to the pull issue, and not actually dependent on the file type.

    And this is new behavior? If so, maybe try rebooting your router, then the TiVo if that doesn't fix it.
     
  2. lpwcomp

    lpwcomp Well-Known Member

    9,461
    298
    May 6, 2002
    John's...
    This is because of the fall update to the Premiere s/w.
     
  3. larrs

    larrs Movie Fan-Addict

    1,028
    6
    May 2, 2005
    DFW
    I'll need a bit more info. Am I assuming I need to edit the metadata.py file? Where should that line be added?



    After a couple of reboots of everything, I got my "computer"icon back and no greyed out share---but the m2ts and ts behavior persists...one step at a time? I could always live with it as is, but it is weird to lose a feature I loved a few days ago. Aren't computers fun?

    By the way, pushes are OK now that the (!) is gone.... weird...but pulls are the same as before, so your theory of them being unrelated is correct.
     
  4. wmcbrine

    wmcbrine Well-Known Mumbler

    11,499
    701
    Aug 2, 2003
    Yes, I know, but that was weeks ago. I said "new". I was trying to determine if he actually saw this change since upgrading pyTivo (unlikely to be more than a coincidence, but I wanted to rule it out).

    No. Have you never used metadata text files with pyTivo?
     
  5. larrs

    larrs Movie Fan-Addict

    1,028
    6
    May 2, 2005
    DFW
    Yes, this change only ocurred toady after the upgrade of pyTivo and my tivos were updated a couple of weeks ago to the latest tivo sw. Nothing else has changed.

    yes, I use metagen for metadata and I added that line to the meta text file with no effect.

    Also seems that pushes through vidmgr also choke on this type of file now (mpg, mp4, vob still work fine) but still tries to create the pytivo temp file for the file; size reports as 0 bytes. This all worked fine before the upgrade today. However, pushes from the pyTivo console still works with these files (as stated above).
     
  6. wmcbrine

    wmcbrine Well-Known Mumbler

    11,499
    701
    Aug 2, 2003
    You don't need to use anything for metadata; it's just a text file, and you only need the one line. In fact, I'd suggest putting just that one line in a "default.txt" in a folder with the problem files.
     
  7. larrs

    larrs Movie Fan-Addict

    1,028
    6
    May 2, 2005
    DFW
    I created a folder in my pyTivo share and dropped in one of the offending files and created the default.txt file as you suggested. It worked.

    My only question is if I can still create my normal metadata text files for each video file as usual, or should the line "Override_container: foo" be inserted into each of my usual meta text files at the beginning. Or, does it matter?
     
  8. wmcbrine

    wmcbrine Well-Known Mumbler

    11,499
    701
    Aug 2, 2003
    default.txt is sufficient. You can do whatever you want for the individual files. The data from both are combined.
     
  9. larrs

    larrs Movie Fan-Addict

    1,028
    6
    May 2, 2005
    DFW
    Thanks for the input. And, happy holidays!

    Given the current state of the process, I can see eliminating vidmgr and streambaby from my world soon.

    Thanks for all the work you do in keeping pyTivo an irreplaceable app. I really wouldn't want to live without it.
     
  10. cweb

    cweb Member

    106
    0
    May 29, 2004
    There has been a lot of back and forth in this thread. Since I'm not the brightest bulb, I've become a bit lots as to how we achieve these blazing pytivo pull speeds. Is it possible for someone to summarize this?

    First it seems you want to make sure you have the latest ffmpeg build. Then you add an entry to your pytivo.conf file that is "ts=on".

    Does the file have to be originally be pulled as a transport stream. In kmttg there is an option to pull the show as a transport stream. Is this the "ts" we are talking about? Can the file be a .tivo or a .mpg2 or does it have to be converted to a mp4?


    Usually I catch on quicker, but all of his holiday turkey may have done me in. As usual, all help is appreciated.
     
  11. kbgators

    kbgators New Member

    27
    0
    Dec 28, 2012
    I have same questions. Please help. Thanks
     
  12. gonzotek

    gonzotek tivo_xml developer

    2,538
    59
    Sep 24, 2004
    Outside...
    The latest ffmpeg(windows builds here, mac builds here) & wmcbrine pytivo releases, and ts=on in pytivo.conf are all required. The file does not need to originally be a transport stream pulled from the TiVo. What is important to the super-fast pull process, however, is that the file contain h.264 video content that the TiVo can playback (level 4.1 or below). It can be stored inside an mkv, mp4, or ts container (and possibly others, I haven't tried). This is the main recent improvement: previously h.264 content would be transcoded to mpeg2 during a pull, now it can be sent without any (slow) transcoding, and since it is significantly smaller than mpeg2, transfers happen very fast. Even if the audio isn't compatible, content starts to transfer virtually instantaneously as transport streams don't need to be complete at the source before sending the first bits out, so pytivo can transcode the audio as it leaves the pc. Pushed content still works as before: If both the video and audio are already in the correct container, transfers happen quickly (once the tivo gets the request from the mind server); if not, they must be transcoded, and/or possibly remuxed into a new file, which can take a measurable amount of time before you can playback the final file on the TiVo.
     
  13. larrs

    larrs Movie Fan-Addict

    1,028
    6
    May 2, 2005
    DFW
    m2ts files also work with the same result. However as you can see in my post above, it did require (at least on my system) a line to be entered into a text file and to reside in the same folder as said file.
     
  14. lrhorer

    lrhorer Active Member

    6,933
    10
    Aug 31, 2003
    San...
    It is of course true it takes less time to transfer a smaller file, but the increase in speed cannot be attributed merely to file size. H.264/MP4 content may be only 30% or so smaller than the same content coded as MPEG-II with about the same perceived PQ, but the files transfer up to 4 times faster.

    The same is sort of true of program streams, if I take your meaning properly. That is to say, as long as the MOOV atom is available, pyTiVo can transcode an MP4 on the fly, even if the file is a PS file. Going from an MPEG-II file to an MP4 is another matter.

    As long as the source CPU is fast enough, one can start watching the video of a transcoded file immediately. The TiVo measures the transfer rate of the video and forces the user to wait rather than potentially encounter pauses while watching the video as can be the case with pulls. With the old AMD Athlon 64 x 2 CPU on my server, transcoded pushes sometimes encountered halts of a few minutes while enough video buffered for the TiVo to be satisfied there would be no pauses while watching. With the new AMD Phenom II x 6 CPU, this never happens.
     
  15. caddyroger

    caddyroger New Member

    1,730
    1
    Mar 14, 2005
    Some where...
    I have a windows 8 pc that I use to download upload programs to my tivo. I download the 6 movies of Star trek last week end and removed the junk form them. I did combine them using videoredo. The total hr was a little over 14 hrs. I use pytivo to upload to tivo but I am not able to to upload more then 6.5 hrs. Would any one know why it not doing more 6.5 hrs?
     
  16. txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    Based on this discussion that a few folks had about a year ago, it looks like Dan203 and DanR figured out some way to incorporate what jmemmott was doing with t2sami into VRDv4.
     
  17. txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    Tivos that can handle H.264 playback accept the mp4 containers as-is. There is no internal remuxing. What you see is just the raw transfer rate of video from PC to Tivo. MPEG2 transfers on the otherhand are actually remuxed again once they hit the Tivo (to whatever proprietary format that Tivo uses, .py or something I believe). I think you have some hacked Series3 machines, so you know what I am talking about. I don't have a hacked machine myself. At any rate, the MPEG2 transfer rate is muddied by the internal processing of the video as it hits the Tivo.
     
  18. txporter

    txporter One sec, almost done

    666
    0
    Sep 17, 2006
    Austin, TX
    I am now using wmcbrine's latest version of pytivo that allows for pulls of H.264 files. I really love it. I can now pull TV shows with correct seriesId into folders. I haven't looked into whether or not the shows seriesId needs to be in the Tivo internal database or not. Does anyone know?

    Also, I guess that it isn't possible to group items into a new user-defined folder using pull the same way that you can with a push? i.e. Movies folder or some such
     
  19. lpwcomp

    lpwcomp Well-Known Member

    9,461
    298
    May 6, 2002
    John's...
    Only on a Premiere.
     
  20. lrhorer

    lrhorer Active Member

    6,933
    10
    Aug 31, 2003
    San...
    Correct. Add to that the smaller file size at the outset and you have a file that transfers up to 4 times faster or a bit more on a THD, especially if it is 720p. Even on a Premiere, it can transfer twice as fast, pegging right up against the 100M Ethernet port limit.

    Actually, it's .ty, short for tystream. No one outside of TiVo seems to know why they call the fail format tystream, but there you have it.

    Yep. Raw tystreams enjoy a similar boost in performance due to the low overhead. It is also why the THD, with its much slower processor, enjoys a much greater gain than the S3 and the S3 more of a gain than the Premiere, but even the Premiere boasts a 2x increase in performance.

    Indubitably. It is also why 720p streams are impacted more than 1080i streams, although I am unsure of the exact details relevant to the fact the 720p streams transfer considerably slower than 1080i streams of the same bandwidth.
     

Share This Page