If William is correct (and I would be willing to bet he is), then I suspect this is not true. I suspect a significant fraction of pyTivo users, and perhaps a majority of them, are not running the latest version. I would be willing to bet $1. By definition, since I do not care, it isn't a problem. You are only partially correct, however. I don't care much about the data being transferred with a push or pull. I do care - albeit not passionately - about the data displayed in the NPL for objects not transferred, particularly the debug data. It aids in troubleshooting. Neither do I, or at least not much, given his post above. It is entirely possible neither approach is tasteful to him. If the OP does not understand why a certain method is employed, then the decision is not fully informed. There are few things I hate worse than so-called user's manuals that do not bother to cover the details and implications of features they putatively cover. It does the user absolutely no good at all to know switch A turns garbeldyfarb inception on and off if the user has no idea what garbeldyfarb inception does or what it implies for the operation of the device. I'll give you a real-world example. Most radio controlled helicopters (and some fixed-wing models) are stabilized by a small piezoelectric or electromechanical gyroscopes. Almost all of these controllers have two modes: rate-lock and heading-lock. None, and I mean none, of the manuals for these devices, even the very most expensive ones, say anything at all about when or why one should employ one mode or the other. Only a very few even mention what the fundamental difference is, although that is fairly easy to discover by testing. I searched and searched, and no one, not even experts could tell me when one mode is better and why. Finally I found someone who was able to tell me. It turns out when attempting certain maneuvers, especially a coordinated turn, having the gyro in head-lock mode makes the maneuver extremely difficult, and almost guarantees a crash. In rate-lock mode, a coordinated turn is essentially automatic. I never said you were. I fail to understand why you would care, but then that is hardly surprising since for whatever reason you refuse to tell us why you are using pyTivo in the first place. Note I am not castigating you for that refusal. It is entirely your right to refrain from disclosing anything at all, but it remains a fact the OP and anyone else will be hard pressed to know whether their desired use of the program would be well served by your methods when they don't know what your desired use is. Again, you are under no obligation to me, the OP, or anyone else to disclose anything. I would indeed be shocked if you were the only one who cares about transferred metadata. Whether the OP might be or why, I have no idea. At a guess, I would suspect it is not extremely high on many people's lists of important features, but I could easily be wrong. According to Arcady there are 7 people who care, although he (she?) failed to understand the situation. Are most people concerned about how much metadata transfers with the video? I really don't know. Is the OP? Other people watching? That is completely irrelevant. Inflatable tires predated the invention of portable electric compressors. That doesn't mean a large minority of people would rather use a bicycle pump to inflate their tires. For at least some of us, vidmgr is a far superior solution. It is faster, requires vastly fewer button presses, is far more compact, and does not require the video to reside on the TiVo. That is was developed later in time than the original utility is utterly non sequitur to its use. So it would seem, and not only do I applaud and appreciate the effort, I'm sure essentially all of us who use pyTivo appreciate it. If a piece of software is given greater capabilities, then it makes the software better, the fact some number - large or small - of users will not take advantage of the feature notwithstanding. William's efforts to that end deserve recognition and respect. Not at all. Clearly you must have considered the details of your approach to have some validity, or you would never have mentioned them. It is the notion of "superiority" in a broad context that is irrelevant, not the suitability of your approach for you and perhaps for the OP if his priorities are similar to yours. Absolutely untrue. Few things are more relevant, facts and figures aside. You have a personal set of preferences. The OP has a personal set of preferences. If his intent and his likes and dislikes are more or less on a par with yours, then his choices may be well served by emulating yours. If not, then he would be best served by other means. It is entirely your personal preference if you happen to dislike fish, but when you report you did not like the fish dinner at a particular restaurant, it is important the reader know you do not like fish in the first place. Without explaining what the impact of that choice would be or why someone might seek a different solution. In short, it does not inform them of the consequences to the user. That is my point. Again, that you choose not to do so is entirely your decision and not my right to question, but it definitely does not fully inform the OP of the consequences. The consequences of using vidmgr and pushes to anyone who does not ordinarily attempt to retrieve the metadata from a transferred video, or in particular one who normally selects the video, possibly inspecting the metadata while doing so, transfers the video to a TiVo, watches the video, and then deletes it from the TiVo are minimal.