MyHD MDP-130 - Page 178

You can also save the channel list to a file and edit the file and then load the file. You could fix all the channels at one time.

Let me test again today and see what happens, I kinda abandoned Titan TV, but it may very well be I didn't do something right.

As a side note, what's the latest version of MyHD. When I go to Help About, I think it says 1.66u, but I believe I downloaded 1.66e from digitalconnection, but on MIT's site they list 1.65.2.

Just wondering....

I'll re-test Titan again and see.

Russ

1.66 is the latest version (u is "US", e is "english", and k is "korean"--I don't think there's any difference between the first two). There is also an updated driver version 1.66.01 that fixes the zero-byte capture bug (I think--but sengsational thinks not--so, Dale, how'd that test go anyway?).

the windows desktop centers just fine under dvi input its the myhd130 thats not centered correctly as for the info on video cards just trying to give all the info i can. so is the scan utility easy to run whats all involved . just dosent make any sense why one tv syncs fine and one dosent but maybe its this world we live in.

Search back in this thread to find sfhub's explanation of how to use both utilities. He did a great job.

My life's too short to spend it chasing will-o-the-wisp Windows problems. If someone can explain to me how to reproduce this thing on one of my PCs with high reliability, I'll take it to MIT. Otherwise, fuggedaboudit.

Hey the zero-byte bug... where can I get the 1.66.01 file? Or verify if I have it? I still on occasion get the zero byte file, but can not reproduce it on the fly.

Russ

ok found the readme and did everything i could and it dosent help it enough seems like it may run better with vga but is this a real digital picture or analog cause its using vga

1.66.01 definitely fixed whatever was causing the 0-byte captures for me. I went from about 1 in 20 failed to zero. That's not to say there is not still some problem that other people are experiencing.

Your life may be too short, but it's MIT's responsibility to make this thing work as advertised. They can handle the work of finding and fixing the bug. You don't need to tell them how to make the problem occur with high reliability. There's a bug somewhere, plain and simple, and MIT can do what's necessary to identify the bug themselves, or expose some debugging information on users' machines.

Download it from the MIT ftp site. When you run the update utility that's inside the zip it will show you both the installed and the "updated" driver versions, so that you can avoid an unnecessary "update".

Fine. Take it to them. It's part of my responsibility not to run to them with problems until I'm convinced that they're actually MyHD bugs and not a Windows configuration problem. This sequenced-file failure appears to me to fall in the latter category, so far.

Jacob, you don't seem to understand that MIT's engineering support for MyHD is a very finite resource and, as such, it is extremely important that we don't squander it in time-consuming bug hunts that benefit a tiny fraction of users (in this case, maybe one?). I won't be party to any claims on MIT time that don't seem to have a large benefit. In this case, there is a clear work-around even for the user who has the most problem. IMO, it doesn't merit MIT treatment until/unless we can give them an exact recipe to demonstrate it.

And...like TStoATSC...MyHD does work as advertised. Read the manual and you'll find no reference to using files named "xxx.0000.ts", etc.

Touché!

I gots just three things to say:

MIT has a responsibility to fix bugs to the core feature set before they add new features. I know that I for one would rather have reliable recording and playback before something like timeshift or simultaneous recording and playback of different programs.

Bugs don't need to be reliably repeatable to be easily fixed. MIT engineers have the resources and knowhow to fix a small bug like this without spending too much time. There is a lot of tools they can use to expose details of what's going on, even on other people's machines. (e.g., a good place to start would be to add some debugging code and perform logging on the machine that's experiencing the problem the most)

You are the gatekeeper to the MIT engineers. I don't see any MIT engineer e-mail addresses on the MIT site, so unfortunately we only have a single route for getting bugs fixed and features added.

This Forum is above and beyond anything that MIT or any manufacturer does to support their products. You, litz, and anyone else can email/post messages to MIT technical support and get the same high level of attention as any other customer.

Bugs do need to be reliably repeatable to be fixed. You've just given several methods to do so that may or may not be available in this case. The intermittant problem has always been the bane of electronics. Fortunately, it's become a rarer beast since we've left the days of vacuum tubes and point-to-point hand-soldered wiring. We're looking at the near end-of-life for this product. MIT is not going to invest in major retooling expenses to find its last bugs.

I think that a poll of MyHD users would find that the great majority believe that its recording and playback are sufficiently reliable. And that they'd really like to have the ability to watch a previously recorded show while MyHD captures a new one. This is my working hypothesis anyway.

amen

Back again with my audio sync. I finally got my .avi recordings to sync with my audio....sorta. If I play the file from the begining and don't mess with the ff/rew it stays in sync just fine. The second I touch the slider bar it's thrown out of whack and I have to start from the begining of the file again.

So, right now I'm just using WMP to playback the .avi files. Is there a player I can use that will allow ff/rew of the .avi without jacking the a/v sync? Or am I going to have to convert to mpeg2 first?

BTW, I was able to fix it by turning off AGP fast writes in the BIOS. That's the only major change I made and the audio sync was nice for 30 minutes. The real test will be Thursday for the next basketball recording.

Okay, I tried to test it again and it looks like Fusion has taken over the association.

What application do I associate the .tvvi and .tvpi files so that MyHD will open them? I tried the MyHD.exe and TitanTVHelper.exe program but I don't think it worked... I'll try some other things tomorrow if I can.

Russell

not exactly....I've had absolutely no problem with DTS audio from DVD players in the past using my current receiver.

I will say this....while DD5.1 is much better using the MDP-130, it still clips every 5-10 minutes or so (albeit very quickly). The DTS audio clips constantly and chops very badly. This was never the case with my past DVD standalone players.

Could this be any sort of PC issue?

My latest trouble with a DTS track was when trying to watch War of the Worlds this past weekend.

Make it five. It happens to me all the time (requires restarting the program) as well as to a friend who owns a hi-class home theater store and is the importer of the MyHD card in Israel.

That's the one. If changing the association in MS Windows Explorer doesn't seem to work, you can rerun the MyHD installation and make sure to have all of the checkboxes ticked on its dialog for associations.

Unfortunately, that doesn't rule out incompatibilities with all sources.
It could be, but I tend to think that it's more specific to the MyHD and your receiver. Have you tried passing the sound via "PC Soundcard" set to "S/PDIF" with your receiver connected to your motherboard's (or soundcard's, if you have one) S/PDIF? Another thing to try is to change coax cables between the receiver and MyHD card.

I don't think lack of support for a file naming convention that is created by a different program/vendor constitutes a bug. It's a feature request, and so goes down the list from JOB #1 with all the rest.

And it doesn't matter if it works on some machines, you just didn't draw the winning card.

I'd love for MIT to support DVICO's naming convention, too. But they don't. So I created the above-mentioned batch file.

So why can't you use a similar tool for your situation?

Xesdeeni

My Solution for using Fusion card is single file. In this century, we should all be using NTFS. There is absolutely no reason to use multiple files with an NTFS file system.

-- Rich

I'm glad there is no reason for you, but some of us have our own reasons, even if they don't appeal to you.

Take archiving. If you want to save a movie to DVDR or CD-R, you must chop it into small pieces. If the recording is from commercial TV, you will probably go through a step to remove commercials, and you can chop it up at that time. But if you are recording from a non-commercial source, why would you want the extra needless step? Recording to media-sized chunks would save time, effort, and hard drive space.

Now think about restoring. You have 3 or 4 DVDRs (or 20-30 CD-Rs) with a movie on them, and you want to watch them. You can copy them to your hard drive and watch them without any processing necessary, if the playback software can handle the multiple files. Again, time, effort and hard drive space are saved.

And there are other reasons, like you may also have to maintain compatibility with other machines or storage devices which use FAT.

"Absolute" is often in the eye of the beholder.

Xesdeeni

.... and the hypothesis is true for me. Being able to watch a previously recorded show while capturing another would be fantastic.


Not getting into the melee, I think that TPeterson is not saying " if I can't reproduce it, it isn't a problem". I interpret him as saying, "if I can't reproduce it, I am not going to expend my time/reputation reporting something that I can't explain." There is a big difference between the two statements. So if you want to get it reported, find a way to reproduce it on 100% of systems. If the numbering scheme is a MyHD bug, and it sounds to me like it IS a MyHD bug, then find a way to reproduce it or make sure that everyone who experiences it reports it.

I suspect that any competent SW engineer should be able to eyeball the source code and tell us under what conditions litz's numbering scheme bug might occur. I'm guessing that all of sequential file numbering is done in a single portion of the code and that manually running through the logic would show when/how/why the shift left-then-tack-on of a "9" occurs vs incrementing to the next number. Personally, I thought that MIT were being generous giving us as much latitude as they do with a numbering scheme. It looks to me like the file name is getting mixed up with their numbering mechanism. It would have been much easier to tightly control the name/numbering and avoid this kind of defect.

I wouldn't like to be told that either. Who told you that? Not I. I've said:

1. I can't reproduce the problem on any of my MyHD systems, despite following all procedures said to provoke it.

2. I haven't (hadn't) heard of its happening exactly as described on more than one system. (Now you and zeev say that there are others, but I'm still not clear on whether they all see this digit rotation that you describe)

3. I personally won't take unconfirmed bugs--i.e., bugs that I do not know how to provoke reproducibly--to MIT (even if you cut my salary ).

4. I strongly believe that requests drawing on MIT resources should be limited to bugs that widely affect MyHD users and features that the majority feel are lacking.

Where in that do I say that you don't have a problem?

Now, I am still unclear on whether or not you can see this problem with the "regulation" (as described in the manual I quoted) MyHD filename sequencing. Can you?

Ok, You gave me one. Backup to DVD. I don't make collections so that was not one that I thought of. Burn to playable DVD would probably not need that since authoring SW is involved.

My solution to backup is Gigabit LAN to another system with lots of space.

To each his/her own.

-- Rich

As near as I can make out, it is a usb problem. At work we have all sorts of devices that stream text data to serial ports. The old way to collect it was to run hyperterminal in capture mode looking at a serial port.

When we use a "new" computer with a USB-serial port, about 2/3 the time it does not work. Go figure. it depends on both the vendor of the USB/seriial adapter, and the mother board