thanks i was able to find a little program to make the symlinks but i was wondering where the files are actually saved or are they in both locations

A symlink is merely a pointer to a directory entry. Some operations, such as reading and writing, typically occur on the data contained in the file referenced by location pointed to by the symlink. Delete operations and certain ohter manipulations on a symlink, however, should only access the link, not the data. A symlink is typically less than 2K in size.

The way I think of it is that a file is physically identified by a number, known as an inode. A directory entry is merely a reference to that inode. When you create a hard link, you are making a second reference to that same inode. The inode knows it is being pointed to by 2 (or more) directory entries. When you delete a file, you are actually deleting a directory entry and decrementing the reference count in the inode. When the reference count reaches 0, the inode is physically deleted and the space is freed. It is very difficult (if not impossible) to break a hard link.

A symbolic link is actually a directory entry that refers symbolically to another directory entry. The inode reference count in this case is still 1. If you delete the actual directory entry, you also delete the inode, and the symbolic link is now broken. If you delete the symbolic link, the original entry, and therefore the inode, knows nothing of what you did.

The way I think of it is that a file is physically identified by a number, known as an inode.

Only on *nix file systems, and not on all file systems on *nix computers, at that. I don't think the ISO 9600 file system employs indoes, for example, even when mounted on a *nix computer. I couldn't swear to it, though.

When you create a hard link, you are making a second reference to that same inode. The inode knows it is being pointed to by 2 (or more) directory entries. When you delete a file, you are actually deleting a directory entry and decrementing the reference count in the inode. When the reference count reaches 0, the inode is physically deleted and the space is freed. It is very difficult (if not impossible) to break a hard link.

That's in *nix. Windows actually does suport hard links on NTFS file systems, but they are arcane and difficult to create and manage. Consequently, no one uses (and few people even know about) hard links in Windows.

That's also why one can freely move files in *nix, as long as the movement does not span logical volumes, without disturbing any reads or writes that are underway. I frequently rename files while the application is writing them. Try that in Windows and it whines about the file being in use.

Quote:

Originally Posted by jbernardis

A symbolic link is actually a directory entry that refers symbolically to another directory entry. The inode reference count in this case is still 1.

Windows symlinks, or "shortcuts" as they are called, work similarly in some respects and differently in others.

Quote:

Originally Posted by jbernardis

If you delete the actual directory entry, you also delete the inode, and the symbolic link is now broken.

Well, not quite. As you mention, there can be multiple hard links, and deleting only one when there exists more than one does not free up the inode. (One does not actually delete an inode, and even when the hard link counter reaches zero, the inode is not released if some process has the file open.) Nonetheless, if the hard link happens to be the directory entry to which the symlink points, then the symlink is broken, even though the inode is still in use by the file. What's more, one does not have to delete the hard link. Simply renaming it will break the symlink.

Quote:

Originally Posted by jbernardis

If you delete the symbolic link, the original entry, and therefore the inode, knows nothing of what you did.

Or rename it, move it to another drive, whatever. As long as the directory entry to which the symlink points remains unchanged, however, the symlink remains intact. It is noteworthy hard links cannot span logical volumes, which symlinks can. Moving or copying a symlink happens in the blink of an eye. Moving a hard link within the confines of a mount point is similarly instantaneous, but issuing a mv command from one volume to another can takes hours or even days, depending on the size of the file and the transfer speed of the I/O system. What actually happens in this case is the file is copied to the foreign file system, a new hard link is created, and the hard link counter for the old inode is decremented by one. If the hard link counter is then zero, the inode is released.

I'm not sure I'd agree with all your statements, lrhorer. I frequently use hardlinks in Windows using the FSUTIL command with the appropriate hardlink create switches, and find it quite a bit more convenient to reference the same file by two different applications. It may be just good timing on my part, but I've not encountered the "file in use" problem with such files. Testing the number of links a files has can be accomplished with the HLSCAN command found in various Resource Kits or Support Tools for Windows.

I'm not sure I'd agree with all your statements, lrhorer. I frequently use hardlinks in Windows using the FSUTIL command with the appropriate hardlink create switches, and find it quite a bit more convenient to reference the same file by two different applications.

Yes, but how many people know about the FSUTIL command or how to use it? What's more, it only works on NTFS file systems, not FAT.

Quote:

Originally Posted by orangeboy

It may be just good timing on my part, but I've not encountered the "file in use" problem with such files.

I think you misunderstand. Forget about FSUTIL. Take a large file, say a video file, and perform some sort of write operation on it. As an example, take, say, a 10GB file named video.mpg and in one window, issue the command

Code:

copy video.mpg video1.mpg

Depending on the speed of your I/O subsystem, that should take at least a few minutes to complete. Now in a second window, issue the command

Code:

ren video1.mpg video2.mpg

You will get an error. Try:

Code:

move video1.mpg <directory name>

and you will get the same error. You will also get the same error if you try dragging the file from one window to another. Try doing the same thing with an ftp client, and you will get the same error.

Not so with Linux. I have scripts, for example, that perform automatic file processing, including moving the files to specific directories and renaming them, while programs like kmttg, VideoRedo, or VAP are creating them. I never have to worrry about whther the apps are done writing to the files, or any such nonsense. I just rename them and / or move them however and wherever I like, as long as I don't attempt to move them outside of the mount point. I never have to wait for a web download to complete in order to rename or move the file.

Quote:

Originally Posted by orangeboy

Testing the number of links a files has can be accomplished with the HLSCAN command found in various Resource Kits or Support Tools for Windows.

I never claimed otherwise. Again, however, how many people know about HLSCAN?

I am wondering if my Premiere is dying or if there is something with PyTiVo pushes that my TiVo is hiccuping on. In the last month my TiVo started rebooting, and I noticed this only happens during a push. Sometimes I have no issues and then sometimes a couple episodes will transfer fine and then reboot in the middle of another transfer.

Any ideas?

This is over a wired connection and my PC is sending them from my WHS via a network share. I am usually pushing AVIs or MKVs. It may just be a bug in 14.8, but I wasn't sure if you knew of anything else that might cause this.

__________________
1 - TiVo Roamio Pro
2 - TiVo Premiere XL

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.

Huh, that's a new one. And this is repeatable -- the same message every time?

Yes, every time.

I was trying to think what might make my computer different and the only think I came up with was that I had pyTivo installed a couple of years ago as a Service. I couldn't figure out how to remove the services so I just disabled it. Deleted the entire contents of the pytivo folder and copied the new code base over.

It looks like you're running pyTivo on Windows, which doesn't support the question mark in a file name. I thought pyTivo was supposed to strip out those 'special' characters but I could be wrong. Can you try transferring a different show and see if it works?

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.

It looks like you're running pyTivo on Windows, which doesn't support the question mark in a file name. I thought pyTivo was supposed to strip out those 'special' characters but I could be wrong. Can you try transferring a different show and see if it works?

I got that with all of the shows that I attempted, but it's working for everything else now.
now I wonder if all of my tests were with the same show just different episode.

Quote:

Originally Posted by moyekj

This looks like an invalid path to me:

Code:

togo_path = E:\Media\Media\Tivo

I'm guessing it has an extra \Media that shouldn't be there.

This is the correct path. Had a reason for this naming convention, but it's obsolete now.

Other than .TiVo format what is the fastest file format to transfer via Push for recorded TV?

An H.264 file in an MPEG4 container transfers more than 4 times faster than the same content encoded as MPEG2 on my S3 and THD machines*. If I transfer a 720p program on my S3s, even with both tuners disabled I still encounter pauses unless I allow about 90 seconds of buffering for a 22 minute program. If I recode to an h.264 .mp4 file using VideoRedo TVSuite, the same program will transfer to my S3 with both tuners active in a little over 7 minutes. Even on my THD, it will transfer in less than 10 minutes.

Most 1080i MPEG2 content will transfer at real time or just a bit better to my S3s with both tuners disabled, unless the bit rate exceeds 17 Mbps average. If I recode to .mp4, a 90 minute movie will transfer in about 30 minutes, and I don't have to bother to disable the tuners.

* - Using the default compression employed by VRD when recoding an MPEG2 file to h.264. This results in about a 30% reduction in file size. It is possible greater compression might yield even faster transfers, but at the potential cost of additional artifacts in the video.

Did you try pushing a properly formatted mp4 file as lrhorer suggested? Sending improperly formated media to tivo can cause all sorts of problems. Lock ups among them. Tivo does not support windows 7 wtv files, they will need to be converted to h264 and ac3 in a mp4 container. Lots of help and utilities to accomplish the task available here.

__________________
Current : Roamio Base with 2TB drive and 2 Premieres and a mini. OTA. kmttg, pyTivo, running with a 78TB Synology 1511 NAS....serving up the world.

Setup help for pytivo under windows: To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Did you try pushing a properly formatted mp4 file as lrhorer suggested? Sending improperly formated media to tivo can cause all sorts of problems. Lock ups among them. Tivo does not support windows 7 wtv files, they will need to be converted to h264 and ac3 in a mp4 container. Lots of help and utilities to accomplish the task available here.

No I haven't had another chance to mess with it yet.

I guess I was going off the assumption MPG would be easier since when KMTTG decrypts the .TiVo file you are left with just an MPG so I was trying to do the same with WTV. It could also be an issue with the profile that they wrote into the MC-TVconverter.

Trying MP4 now and I don't think this is going to work for us. MP4 just takes way too long to convert from WTV since we record so much.

I have been using Pytivo for quite a while now (Current version installed 2009), but have recently "cut the cord" and cancelled Cable TV, so want to update to the latest version. (sounds like it has video push? And hoping to get pictures working?)

How do I update to the most recent version without jacking my current install?

I have been using Pytivo for quite a while now (Current version installed 2009), but have recently "cut the cord" and cancelled Cable TV, so want to update to the latest version. (sounds like it has video push? And hoping to get pictures working?)

How do I update to the most recent version without jacking my current install?

You just have to download the zip for the lastest release if you are using windows can't help with linux. Extract to the pytivo folder and that should be fine it will ask to overwrite the files there just say yes. If you like just make a backup of your pitivo folder.