You could even create aliases for the actions, but as little as you will likely be using them, it probably isn't worth it.

Once you are done getting everything set up, you can also expect to very nearly forget it exists. As long as the system has a good UPS supplying its power, it will just sit and run for months on end. Note the uptime on the screenshot I posted in your other thread: 4020 hours. That's nearly six months. The backup server has been running a similar amount of time.

First i want to say this this is an amzaing piece of software. It is what i have been looking for, for a long long time.

I am having some trouble getting the mettadata to show when i enter Vidmgr.

The vidoes are transferring correctly and play beautiful.

I think i have my mettadata coded incorrectly.

I am using ThumbsGen to pull all the data. It is making the correct files but i still dont see any data when i log in.

All i see is the title of the movie and a green dot next to it.

Also is there any way to view the thumbs or titles in a "grid" view instead of a list.

Below is the copy of my ini file

Thanks for any help and keep up the amazing work!!!

# vidmgr.ini
#
# this is the global options file - it belongs in the vidmgr directory under pyhme
#
# Default values are specified below.

#
# NOTE:
#
# These default values do NOT need to be explicitly stated in this file. They are here for illustration
# you can leave them in here if you want, or you can remove them and only include in here the options you
# are changing
#

#
# vidmgr section is mandatory
#

[vidmgr]

#
# what file extensions are we interested in. Only files with these extensions will be
# displayed on screen
# specify a list of file extensions - with the . - separated by at least one space
#

exts=.mp4 .mpg .avi .wmv .mkv .mts

#
# the next 4 options specify format information for the info screen that pops up
# when you press the info button.
# specify a list of metadata tags for each.
#

#
# the next two options are also formatting options for the info screen. The info screen is
# a two column layout. the infolabelpercent option indicates what percentage of the
# screen width should be devoted to the label column
#
# the inforightmargin option specifies the width of the right margin on the info screen. If
# you find the text running up against the right edge of the screen, increase this number.
#

infolabelpercent=30
inforightmargin=20

#
# the next two options control how multiple metadata files are handled. When searching for
# metadata, vidmgr looks for the files in the following sequence:
# .meta/default.txt
# default.txt
# .meta/<videofilename>.txt
# <videofilename>.txt
#
# metamergefiles determines if the contents of one file are merged with previous files or if
# it completely replaces the previous file. If this is set to true, since the files are read
# from the general to the specific, more specific information will replace more general information,
# but the end result will be the union of all the files. If this is set to false, then only the
# information in the last file read will be kept.
#
# metamergelines if only meaningful if metamergefiles is set to true. If set to true, then if
# two files contain the same metadata tag, then the values are concatenated together. If set to
# false, then the value from the second file replaces the value from the first file. Note -
# metadata tags that are already lists (vActor, etc) are always merged regardless of the value of
# this option.
#

metamergefiles=True
metamergelines=False

#
# specify the point size of the font used to display the descriptive text of a video on the main screen
#

descsize=50

#
# the image files that vidmgr uses for its background, etc, can be replaced. These files all reside
# in a directory named 'skins' under the vidmgr directory. If you wish to use your own image files,
# create a directory under skins, place your files there, and name that directory with the skin option.
# Note: the files must be png files and must match the original images in size. Only the images being
# changed need be specified. If an image file is NOT found in your skin's directory, the corresponding
# file is taken from the main skins directory.
#
# There is no default for this. Do Not include this option unless you are using your own skin
#
# skin=

#
# can the files in this directory be deleted - specify true or false.
#

deleteallowed=False

#
# specify how you would like the artwork for a video to be justified - specify left, center, or right
#

thumbjustify=left

#
# specify the name of the file to use for the folder and for the video file if a video specific file is not found
#

thumbfolderfn=folder.jpg

#
# what metadata tags should be used to construct the string used to identify this file on the screen
# specify a list of metadata tags - including any metadata tags you may have created yourself. In addition to the
# normal metadata tags, you can use the word 'file' to indicate the video's file name (without the directory) and
# you can use the value 'titleNumber' to indicate the title number for a DVD video.
#

display=title episodeTitle

#
# what string should be used to separate the above metadata when constructing the title string
# specify an arbitrary string
#

displaysep=:

#
# what metadata tags should be used to construct the string that is used to sort the videos when they
# are displayed in a list specify a list of metadata tags - including any metadata tags you may have created yourself. In addition to the
# normal metadata tags, you can use the word '__fileName' (or 'file') to indicate the video's file name (without the directory),
# '__filePath' to indicate the video's full directory path, or the value 'titleNumber' to indicate the title number for a DVD video.
#

sort=title episodeTitle

#
# which direction should the sort be
# specify up for an ascending sort or down for a descending sort
#

sortdirection=up

#
# should a leading article (the, a, an) in a 'title' or 'episodeTitle' be ignored when sorting on that title. Note that the displayed
# title will not change i.e. "The Abyss" will still show up as "The Abyss", but it will be sorted in with the A titles.
#

ignorearticle=True

#
# the next options control the contents of the top of the navigation tree. If sharepage is set to true, the top page will
# contain an entry that says 'Browse Shares'. This will take you to a separate page where the shares are listed.
# If it is set to false, then each share will be on the top screen.
# if sortroot is true, the virtual shares and the actual shares will be sorted together. If it is false (the default)
# then the actual shares will appear above the virtual shares. Both will be sorted, but one will appear before the other
#

sharepage=true
sortroot=false

#
# what text string should be used for the subtitle on the top navigation screen. The subtitle normally gives
# a cue as to where you are in the navigation, but no such cue is necessary when at the top; this string will
# be displayed instead
# default: topsubtitle=Main Menu
#
# topsubtitle=

#
# by default, vidmgr will check file unique IDs so that it knows if two files are actually the same file with two
# different links. On windows, this is an expensive operation. This affects the amount of time needed to build
# the cache. If you are not using links in your video directories, you can essentially disable this logic by
# setting the following option to false. The default is true
#

usefileid=False

#
# the tivos section of the file is where you identify your Tivos. For each tivo, you MUST provide a name and
# a TSN. It is NOT necessary to put the dashes into the TSN - just use the digits. In the tags below, replace the
# X with a digit starting at 1 (e.g. tivo1.name). If you have multiple tivos, number them sequentially. You can have
# an arbitrary number of tivos, but vidmgr will stop parsing the file as soon as it detects a gap in the
# numbering sequence. These fields have no default values.
#

[tivos]
tivo1.name=LivingRoom
tivo1.tsn=746XXXXXXXXXX

#
# the pytivos section is where you identify your pytivo processes. The tags are numbered as above - replace the X
# with a digit starting from 1 andproceeding sequentially from there. You MUST provide config - which is a full
# path to the pyTivo.conf file, and ip - which is the ip address of the machine on which pytivo is running. If
# the config file does NOT specify a port number for pytivo, then you MUST specify it here. pytivoX.skip is a
# comma-delimited list of shares that you do NOT want to include here - do NOT use extra spaces in this list.
# pytivoX.sep is the file path separator for the machine on which pytivo is running - if this is omitted, then
# the seperator character for the machine on which vidmgr is used.
#

#
# now come the virtual shares - there can be an arbitrary number of these. Whatever text you put between the square
# brackets as the section name will become the text that appears on the navigation screen. Each virtual share MUST
# have a specification for which files to include. Additionally, you can override sort and display options, and you
# can specify how files should be grouped
#
[Movie Library]
values=all
#
# there are four possible ways to indicate which files to include. You must use exactly 1 of them for each virtual share:
#
# 1. specify which metadata tags are used to divide videos up into groups:
#
# tags=tag1 tag2 tag3 ... tagn
#
# each video is searched for the specified tags. If a video does not have ANY of these tags, it is skipped. If it has ANY
# of the tags, then the video file will be inserted into a group for each value. For example, if the tag was vActor, then
# for each actor in a file, that file would be inserted into a group with that actor's name as the group name. As other
# videos are found with this same actor, they will be added to the existing group. What you end up with is a main menu choice
# for the virtual share (the text in the brackets) and when you choose it, you will see all the actors found in the metadata
# as separate "folders". If you then navigate into those folders, you will see all the videos that each actor is in. In addition
# to all of the normal metadata tags, including your own, you can use titleNumber which is the title number for DVD titles.
#
#
# 2. specify metadata VALUES that must be matched for a video to be included:
#
# values = tag:val,val.../tag:val,val...
#
# each video is searched for the specified tag(s). If a video does not contain any of the tags, it is skipped. If it DOES
# contain a tag, then the value for that tag MUST be one of the values listed. If it's not, then the video is skipped. If
# multiple tags are specified, a video will match only if 1) it contains ALL of the tags, and 2) each value for EVERY tag
# is in the specified list. Spaces are significant for the values. Do not use any unnecessary spaces in the specification.
# As an example, values=isEpisodic:true,True,TRUE will include ALL videos for which the value for isEpisodic is true, True,
# or TRUE. As with tags, the metadata tags can be any of the normal tags, including your own, or titleNumber which is the
# title number for DVD videos.
#
#
# 3. select videos based on a metadata tag, but group them into alphabetical folders (e.g. "A", "B", ... "9", "<Other>")
#
# alpha = tag
#
# for example, specifying alpha=Title will organize all videos into title order, but it will produce a separate "folder"
# for each occurring letter or digit. Titles that do not have a leading letter or digit are placed into an "<Other>" folder.
# Only letters and digits that have at least one video will be presented. The ignorearticle option affects Alpha shares
# if the tag is either 'title' or 'episodeTitle'
#
#
# 4. include ALL videos unconditionally:
#
# values=all
#
# this is useful in conjunction with the other options below. For example if you want a share that includes all videos
# sorted by record date.
#

#
# within the videos selected for a virtual share, you can add one layer of grouping. This is provided by the groupby
# option. The tags option above already offers a layer of grouping, so this option is probably more useful for the
# values and alpha options, but it CAN be used with tags.
#
# to use this option, specify a SINGLE metadata tag. For each matching video, the value for this tag is used to create/identify
# a "folder" into which this video is placed. If the video does NOT contain the tag, then the video is placed in the root
# "folder". As a good example, let's extend the isEpisodic example from above. If you say "values=isEpisodic:true,TRUE,True"
# all videos will show up in a single flat "folder". They will be sorted, but it could be a large list. If I
# add "groupby=seriesTitle", then vidmgr will create "sub-folders" for each series title thus organizing the files.
#
# groupby=

#
# you can specify a different sort order for the tags you are organizing by as opposed to the video titles themselves. The videos
# are governed by the sortdirection and sort parameters, but the sort order of the tags is determined by the tagorder parameter, set
# to either up (default) or down. This allows, for example, for the movies to be organized by year with the newest first, but within
# a single year the titles would be in normal alphabetical order.
#
# tagorder=up

#
# it is possible to limit the selection of videos for a virtual share to a list of physical shares by using the
# shares= statement. If omotted, ALL shares are considered as a source for videos
#
# shares=
# for example if all of your movies are in a share titled "My Movies", then then following
[Movies Alphabetically]
alpha=Title
shares=MyMovies
#
# will create a virtual share containing all videos from the My Movie share organized into alhpabetical folders

# finally, it is possible to override the sort, sortdirection, display, and displaysep options for this virtual share
# by simply specifying that option in the corresponding section. If these are missing, then the global values will be used.
#
# display=
# displaysep=
# sort=
# sortdirection=

# the next two options control how multiple metadata files are handled. When searching for
# metadata, vidmgr looks for the files in the following sequence:
# .meta/default.txt
# default.txt
# .meta/<videofilename>.txt
# <videofilename>.txt
#

Do your metadata files match the specified naming standard and location? For example, if you have a video called "My Movie.avi" the metadata file needs to named "My Movie.avi.txt" and reside in the same folder as the .avi file or in a subdirectory named .meta (notice the leading period, that's important).

Quote:

Originally Posted by techguy82

Also is there any way to view the thumbs or titles in a "grid" view instead of a list.

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Do your metadata files match the specified naming standard and location? For example, if you have a video called "My Movie.avi" the metadata file needs to named "My Movie.avi.txt" and reside in the same folder as the .avi file or in a subdirectory named .meta (notice the leading period, that's important).

I have set the Metadata files the way you suggested but still the same result.
i.e "300.mkv" i have a subdir \.meta\ and then placed 300.mkv.txt and have also have default.txt with in the dir as well.

I looked the code in the TXT and they are pointing to images links for the cover art. Is that correct or should it be pointing to the image saved in the DIR?

I am seeing this message when the Vidmgr boots "Video Cache does not exist - attempting to build..."

Could there be something else i am missing?

Off hand Question:
When the Meta Data is done correctly, will it show in the My Shows Section when you play the video?
The section that shows information about the show you are about to watch.

And Lastly:
I have 2 sources of videos. MyMovies & Television.
What i would like to do is have them to show up as two different sources with the metadata not in the directory view.
Right now they are all showing in 1 folder, unless i view them in the shares section.
Is that possible?

I have set the Metadata files the way you suggested but still the same result.
i.e "300.mkv" i have a subdir \.meta\

That would be a .meta directory in the root of the drive. The .meta directory needs to be in the root of the share. Thus, if the share is c:\videos, the meta directory for the videos in that directory (but not its subdirectories) would be c:\videos\.meta

Quote:

Originally Posted by techguy82

and then placed 300.mkv.txt and have also have default.txt with in the dir as well.

Is 300.mkv the only video in its directory? If not, then a default.txt metafile referencing 300.mkv is probably not proper. The default.txt metafile would ordinarily hold information relevant to all the files in the directory.

Quote:

Originally Posted by techguy82

I looked the code in the TXT and they are pointing to images links for the cover art. Is that correct or should it be pointing to the image saved in the DIR?

Pointing? I'm not certain what you mean by "pointing". There should be nothing like a link in the metafiles. Any photographic images are a separate item altogether. The naming convention for them is the same as for the metafiles, except of course the extension is .jpg, not .txt.

Quote:

Originally Posted by techguy82

I am seeing this message when the Vidmgr boots "Video Cache does not exist - attempting to build..."

Could there be something else i am missing?

It sounds like it. What happens when you try to build the cache manually? I'm not sure, but this:

Thanks that did the trick i can now see the meta data on the tivo!!\
However the Pix and the movie rating is not showing on the tivo screen when viewing the info. it shows up as TV-NR. Is it able to do that?

You mentioned that i can build the Cache manually. How would i do this?

Also when starting

I am on a windows box if that matters.
Once again thank you for your help.

I have all of my videos on a NAS connected to the same network as the tivo.
The structure is
\\Mybooklive\public\MKV Movies\21\21.mkv
\\Mybooklive\public\MKV Movies\300.300.mkv
\\Mybooklive\public\MKV Movies\8 mile.mkv

With in those DIR i have the Thumbnails
\\Mybooklive\public\MKV Movies\21\21.mkv.jpg
\\Mybooklive\public\MKV Movies\300.300.mkv.jpg
\\Mybooklive\public\MKV Movies\8 mile.mkv.jpg

Then i have the Metadata
\\Mybooklive\public\MKV Movies\21\21.mkv.txt
\\Mybooklive\public\MKV Movies\300\300.mkv.txt
\\Mybooklive\public\MKV Movies\8 mile.mkv.txt

Is this the correct way?

It will work, if that is what you want. There are lots of "correct" ways to skin this cat. I would say most people would not want to devote an entire directory to a single video, but it is entirely up to you. What I like to do is create a main pyTivo share with everything but the DVDs in it. (DVDs require a separate share and a different directory structure.) In that main share are all the movies except those that are part of a movie franchise. Each movie franchise or TV series, however, gets a separate directory in the main share. Thus, there are over 1000 videos plus the same number of thumbnails and metafiles sitting directly in /RAID/Recordings. In addition to those, there are about 100 subdirectories, each one containing two or more movie franchise installments or TV series episodes. Thus, "/RAID/Recordings/Harry Potter" contains the following:

Thank that was what i needed!!
As far as the metadata is that only seen in Tivo? or can that be seen in the Vidmgr as well.

The Description field pops up whenever the cursor sits over a video title. Pressing the <Info> button pops up a listing of the entire metafile, sorted in the way you specify in the vidmgr.ini file, and excluding any fields you explicitly exclude there.

Quote:

Originally Posted by techguy82

Also what about the Pix and the rating will that be shown in the tivo info screen?

Some fields transfer, and some do not. I don't recall which off the top of my head.

Any metatags you create yourself will definitely not transfer, but they are a powerful means of managing the vidmgr display. For example, if you will look at the sample virtual shares above, you will see one based on the firstAlpha tag. This tag simply contains the first capitalized character (i.e. A - Z) in the film's name, excluding any articles, unless the first character is a number, in which case the tag contains the text "0 - 9". Vidmgr then creates 27 virtual folders, one labeled "0 - 9", and 26 labeled "A", "B", "C", etc. Programs like 9 to 5 and 50 First Dates show up in the "0 - 9" folder, while The Abyss shows up in "A", Brewster's Millions shows up in "B", etc. This makes looking for a specific title much, much faster and easier.

For example:
I would like to have it more like a Netflix layout not in a single column but in a grid Layout with the Thumbs showing for each movie. Then you would click on the thumb and it would enter into the info screen showning Meta data or a MovieInfo thumb created by ThumbsGen. At the bottom of the MovieInfo jpeg there would be the option to transfer ( then pop up to pick which Tivo you want to transfer to, if you have more then one) and any other features that i might not be aware of.

When viewing the " browse shares" section it looks like this might be pretty easy to do, especially if you have the movies set in their own directory. The Directory would be the movie thumb and when entering the folder the thumb would be the movieinfo thumb. The layout would need to be changed to 2 or 3 row layout instead of column when entering the directory. Attached is a sample of the MovieInfo thumb.

Let me know your thoughts on this and if it would be possible. If so what type of programming language would be need to make these changes

Also what meta editor would you suggest using. ThumbGen is not giving me the correct file structure
Thanks

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. | To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

There are a large number of config options in vidmgr.ini. I suggest you read through them.

Quote:

Originally Posted by techguy82

For example:
I would like to have it more like a Netflix layout not in a single column but in a grid Layout with the Thumbs showing for each movie.

Nope. A list of 14 titles is the best you are going to do. It beats the heck out of 8 in the NPL, plus the vidmgr list advances 14 titles per page, not 7 like the NPL.

Quote:

Originally Posted by techguy82

Then you would click on the thumb and it would enter into the info screen showning Meta data or a MovieInfo thumb created by ThumbsGen. At the bottom of the MovieInfo jpeg there would be the option to transfer ( then pop up to pick which Tivo you want to transfer to, if you have more then one) and any other features that i might not be aware of.

No. Just highlight a video and press <Info> for more information, or <Select> to transfer it (or delete, if you have that option enabled).

Quote:

Originally Posted by techguy82

When viewing the " browse shares" section it looks like this might be pretty easy to do, especially if you have the movies set in their own directory. The Directory would be the movie thumb and when entering the folder the thumb would be the movieinfo thumb. The layout would need to be changed to 2 or 3 row layout instead of column when entering the directory.

If I follow what you are saying, Jeff would have to disable the Info and Thumbnail displays. I vote, "No."

Quote:

Originally Posted by techguy82

Attached is a sample of the MovieInfo thumb.

No, thanks. That would be a huge time waster.

Quote:

Originally Posted by techguy82

Let me know your thoughts on this and if it would be possible.

I'm sure it is possible, but it sounds like nothing I would choose to use.

Quote:

Originally Posted by techguy82

If so what type of programming language would be need to make these changes

HME for Python and its plug-ins are wtitten, strangely enough, in Python.

Quote:

Originally Posted by techguy82

Also what meta editor would you suggest using. ThumbGen is not giving me the correct file structure
Thanks

I used to use metagenerator, but that was before I started using kmttg. If your files are not originating on the TiVo, though, you will need to use something like Metagenerator or MetaGen, or just create them by hand using a text editor.

But there's no repeat of that message in /etc/log/boot, and VidMGR is working fine. Tested pushing an .avi & .mpg thru PyTivo Video Manager, no problems.

There's no error indication in either pyTivo.log or pyhme.log, and there's no pyhme.err file. There's also no other errors in booting, except the perpetual ALSA amixer error which I've given up on and don't care about (much).

This is not a big deal, just strange. This after one of my brand new 3tb drives in my brand new server conked out, replaced it, rebuilt array (won't get into what sort of array), and all is well except this tiny anomaly.

Any ideas or pointers where to look next? Is this message emanating from the start of OpenBSD Secure Shell server or just happens to follow?

Hmm. That looks to me like the HME for Python script chain is returning a value other than 0, but is still getting things far enough along to have HMEfP running. Let me take a look tonight.

Edit: Upon consideration, I am thinking it is more likely this may be something from sshd, or even something else. By default, startpar runs the init scripts in parallel to save time, so it is possible an earlier script is failing by coincidence at the same time HME for Python is starting.

I suggest you try this: add the line

Code:

exit 0

to both the HME for Python and pyTivo init scripts in /etc/init.d just below the LSB header section. After you have done that, reboot. See if the error pops up again. If so, it's not pyTivo or HMEfP that is returning the error. Of course, after trying this, remove the line from both scripts and start the daemons. (There is no need to reboot a second time.)

FFMEG is working correctly i think. it begins the trasncode and makes a pytivo.temp file in the dir. the transfer never takes place to the tivo and i get an error on pytivo "[Errno 10054] An existing connection was forcibly closed by the remote host."

It looks like the pytivo makes the temp file and then tries to transfer but is denied or the socket it was trying to connect is now closed because it took to long to transcode, but i am not sure

MKV Size is 22.9GB i have successfully transferred 30Gb MKV to the tivo so i dont think it has anything to do with the file size.

Any way to fix this?

Thanks Again!!

PS.
It takes about 2 hours for me to be able to play the file (not fully downloaded on to the tivo) any way to speed this up?

Running PyTivo on a E5200 with 2gb ram & Nivida GT 220

I am thinking about getting a much more powerful system but wanted to know if it would improve speeds greatly

FFMEG is working correctly i think. it begins the trasncode and makes a pytivo.temp file in the dir. the transfer never takes place to the tivo and i get an error on pytivo "[Errno 10054] An existing connection was forcibly closed by the remote host."

It looks like the pytivo makes the temp file and then tries to transfer but is denied or the socket it was trying to connect is now closed because it took to long to transcode, but i am not sure

That is not an unlikely explanation.

Quote:

Originally Posted by techguy82

MKV Size is 22.9GB i have successfully transferred 30Gb MKV to the tivo so i dont think it has anything to do with the file size.

No, it shouldn't.

Quote:

Originally Posted by techguy82

Any way to fix this?

I suspect what is happening is the MOOV atom is getting in the way. Many h.264 coders put the MOOV atom at the end of the file, but TiVo needs it up front. I suspect that is why ffmpeg is creating a temp file. There may be a more sophisticated solution, but the most straightforward, I think, would be to convert the file into a format the Tivo can handle before attempting the transfer. For pushes, that might be h.264 in a .mp4 container. For pulls that would be MPEG-II.

Quote:

Originally Posted by techguy82

It takes about 2 hours for me to be able to play the file (not fully downloaded on to the tivo) any way to speed this up?

Again, I suspect that is due to the location of the MOOV atom. Use something like VideoRedo TV Suite to transcode your videos (maybe all of them) beforehand, and it should speed things up a great deal.

Quote:

Originally Posted by techguy82

I am thinking about getting a much more powerful system but wanted to know if it would improve speeds greatly

1. pyTivo sees that the file has video (h.264) that is potentially TiVo-push-compatible, but is in the wrong container format (MKV). (I'll ignore audio in this discussion for simplicity.)

2. So, pyTivo takes the file and remuxes it to a TiVo-compatible MP4 container. This is the temporary file in question. This is only done when remuxing; transcoding does not result in a temporary file.

3. pyTivo contacts the TiVo mind server to let it know there's a file available. Notice that it makes no difference how long it takes to create the temp file, because the notification doesn't occur until after it's done. Also, pyTivo never, ever makes an outgoing connection to the TiVo (except as part of the beacon system).

4. The Tivo, at some unspecified later time (usually quickly, often not; we have no control over it), contacts the mind server on its own, and receives the notification. Then it requests the file from the pyTivo server.

5. In this case, the TiVo rejects the file. This is not unusual. We don't know all the limits on what types of h.264 the TiVo will accept, and to be honest we don't even test for all the ones we do know.

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. Alternatively, you can of course try reencoding it to h.264 (again) on your own, and re-pushing it, but that seems to me like a lot of work for an uncertain outcome.

techguy82, if you post the output from "ffmpeg -i badfile.mkv", it may be possible to figure out what the TiVo doesn't like about it. Then again, it may not.

Quote:

I suspect what is happening is the MOOV atom is getting in the way.

No. pyTivo passes MP4 files through "qt-faststart" as it sends them, which moves the MOOV atom to the front. This is also why the MP4 remux creates a temp file -- because it's impossible to create the MOOV atom until the file is done, the MP4 can't be streamed as it's created, unlike the MPEG-2 program streams pyTivo creates.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

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.

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.)

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

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?

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.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

1. pyTivo sees that the file has video (h.264) that is potentially TiVo-push-compatible, but is in the wrong container format (MKV). (I'll ignore audio in this discussion for simplicity.)

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.

Quote:

Originally Posted by wmcbrine

2. So, pyTivo takes the file and remuxes it to a TiVo-compatible MP4 container. This is the temporary file in question. This is only done when remuxing; transcoding does not result in a temporary file.

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

Quote:

Originally Posted by wmcbrine

3. pyTivo contacts the TiVo mind server to let it know there's a file available. Notice that it makes no difference how long it takes to create the temp file, because the notification doesn't occur until after it's done. Also, pyTivo never, ever makes an outgoing connection to the TiVo (except as part of the beacon system).

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

Quote:

Originally Posted by wmcbrine

5. In this case, the TiVo rejects the file. This is not unusual. We don't know all the limits on what types of h.264 the TiVo will accept, and to be honest we don't even test for all the ones we do know.

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.

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.

Quote:

Originally Posted by wmcbrine

Alternatively, you can of course try reencoding it to h.264 (again) on your own, and re-pushing it, but that seems to me like a lot of work

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.

Quote:

Originally Posted by wmcbrine

for an uncertain outcome.

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.

Quote:

Originally Posted by wmcbrine

No. pyTivo passes MP4 files through "qt-faststart" as it sends them, which moves the MOOV atom to the front. This is also why the MP4 remux creates a temp file -- because it's impossible to create the MOOV atom until the file is done, the MP4 can't be streamed as it's created, unlike the MPEG-2 program streams pyTivo creates.

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.

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

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.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.