PDA

View Full Version : inserting ty+ file w/ mfs_ftp doesn't recover prog info



tivofnd
06-14-2006, 08:14 PM
My wife accidentally deleted my son's favorite program this morning. Fortunately, I had extracted the ty+ file for the purpose of putting it on a dvd to take when we travel. I've tried using mfs_ftp to insert it but it just names the program filename.ty. I've tried renaing the file to .ty and .ty+. I even tried using the original file name with all the {} but it just wraps a pair of {} and takes the whole thing as a single string. I have verified that the program info (XML data) exists at the end of the ty file.

Searched and read everything I could find on this forum about insertion but most imply that if I just upload a ty+ or tmf file, then it'll recover everything. Am I doing something wrong? Please advise. Feel free to point me to the correct post if this has been discussed already.

Thanks in advance for any help.

idoco
06-14-2006, 09:53 PM
If you have TivoWebPlus installed you should be able to undelete the program. Look under User Interface/Deleted Shows

Idoco

Jamie
06-15-2006, 01:29 AM
My wife accidentally deleted my son's favorite program this morning. Fortunately, I had extracted the ty+ file for the purpose of putting it on a dvd to take when we travel. I've tried using mfs_ftp to insert it but it just names the program filename.ty. I've tried renaing the file to .ty and .ty+. I even tried using the original file name with all the {} but it just wraps a pair of {} and takes the whole thing as a single string. I have verified that the program info (XML data) exists at the end of the ty file.

Searched and read everything I could find on this forum about insertion but most imply that if I just upload a ty+ or tmf file, then it'll recover everything. Am I doing something wrong? Please advise. Feel free to point me to the correct post if this has been discussed already.

Thanks in advance for any help.tmf insertion tends to be more reliable in my experience. There's a ty+2tmf.pl script posted you can use to convert to tmf.

tivofnd
06-16-2006, 01:58 PM
Sorry I wasn't on yesterday... got slammed at work. Both suggestions were very useful. I was able to undelete (guess I should have read TivoWeb+ docs more carefully). I was also able to insert a program after converting it to tmf and it looks like it retained the program info. I didn't get a chance to try to play it though. One problem I ran into is that one of my ty files has the "Priority Set..." turd in it. I thought I'd re extracted all the recordings that had this problem but I guess I missed one. The "unpriority" program doesn't catch this case. After looking at the source, it looks like it only checks on chunk boundaries which is probably fine 99% of the time. In this case, the turd appears at the end of the last chunk. My guess is that the last chunk is not a full chunk so unpriority misses it. I'm planning on rewriting that part to remove all occurences of the "Priority Set..." in the file no matter where it appears. Does anyone see any problems with that?

Jamie
06-16-2006, 02:26 PM
I'm planning on rewriting that part to remove all occurences of the "Priority Set..." in the file no matter where it appears. Does anyone see any problems with that?There is a very slight possibility the "Priority Set..." string could occur in a valid video stream. Seems like it is so unlikely that it isn't really a problem, but I haven't thought too hard about it.

The algorithm is likely to run slower if you try finding "Priority Set..." anywhere in the stream rather than only at chunk boundaries. It might be a smarter algorithm (http://en.wikipedia.org/wiki/String_searching_algorithm) would help. Ultimately I'd expect this sort of searching ought to be disk bound rather than cpu bound.

tivofnd
06-16-2006, 03:20 PM
Here's my version of unpriority.c. I'll call it unpriority2.c for sake of clarity. I reimplemented the scan do be more exhaustive. It will now scan through the whole chunk rather than just the beginning. Speed should not suffer too much since I only resort to string compare when first and last characters match. The old logic also skipped the check completely if there's less than a full chunk on the last read which I think is what I hit. I've compiled and tested on Linux.. Don't have build env on windows but it should compile with minimal tweaking. It seems to work for the problem file that I had. Let me know what you guys think.

tivofnd
06-16-2006, 03:47 PM
Thanks for the feedback Jamie. In my case, it wasn't causing problems in the video stream. I was actually able to demux, remux, and trancode the video fine but since the turd was right in front of the xml content of the ty+ file, ty+2tmf.pl would fail to generate a tmf file. Well, it creates a 0 length file which doesn't help. :) I would agree that the chances of this string appearing really as part of a video stream is highly unlikely. Actually, probablility is approx 1 in 256^16/size of file. That means 1 in 3.4e29 per gig.

I did consider performance and came up with a pretty simple solution that does all the work in memory and doesn't read the file multiple times. Plus, it avoids doing a full string or mem compare unless it passes an intial (cheap) sniff test which is 1 or 2 char compares. The implementation also catches any turds that span chunks (which I don't think will happen). The cost for this second piece is simply that it will read slightly less than a full chunk when we get less than 16 bytes from the end of the last chunk. Across even a large recording, that's probably going to account for just a few additional chunk reads at most. I think it's a decent trade-off.