@ mosse_t I've checked my Medion remote, and there is only 1 TV Medion model available (no description). So i'm afraid I can not help you there. My old Lidl rc has far more models available, but it only mentions numbers, not models; which makes it unpracticable to try out... (Lidl rc model URC-L-1870) If you google, you'll find the rc available (like on ebay); or you could try with a recent Lidl rc.
you can; just do not connect Hercules to your Com port while WinLirc is running (and connected to that very same port).
in the meantime, I've simply restored my recent ghost copy of windows 7 (as I first wanted to see if it was a hw problem, rather then a sw one); and everything is fine again. This means that the aforementioned situation causes some sort of driver conflict (under win 7?). I'm pretty sure this can be resolved without such a drastic restore, but i'm not planning in reproducing this on purpose
as for liyin: do i understand that the winlirc server is listening on port 8765. I did precisely what is shown in your printscr (and explanation), but no response if i just send some codes via winlirc... is it obligatory to have a receiving programming running ? in this last case, i read then: winlirc receives incoming ir codes (from a remote control), then sends it to an application over port 8765 ?! Bs player can work with winlirc; at least i saw an option reference there. so i could try that...
Is this a means to test that your (hex) codes are sent ? I tried this with Hercules, but ping-ing gives an error... (wrong port?)
btw: this gave me some problems ?! as it did not work, I changed to the Serial TAB, and tried to open the COM3 port (in my case). that gave an error (conflicting with WinLIRC I assume). I quit WinLIRC, but still no go. Ended up rebooting my PC, and tried only Hercules on COM3, but I get no response (with T command) at all now. So: I decided to bridge my UIT so that it would appear in my HID overview, and thought I would find the TCPIP port there. Unfortunately, I got a driver error now (similar to the one I got when using the terminal with $). Luckily, it did not lock up my UIT. Tested it afterwards, and still working (i can still program my rc).
bottomline: something went wrong when conflicting between WinLirc and Hercules. I'm pretty confident that if I update the firmware again under XP that it will work (but i'm not bothered for the time being)... (note: when it did work and I sent a T command, I only get a FA02 message whether pointing to a white sheet or not). When I first connected the UIT - with its original firmware - it immediately returned V102 (or v101, can't remember exactly))
i did not even know about a CC-BY-SA license till you mentioned it hei man, it's yours, and use it like your own property. I got a few more: if you would like to have the originals, i can mail them to you (rar is about 15 MB); or i can upload small sizes here...
did all your suggestions, and some more (like copying new header in working config, dis/enable repeats, out of plastic case). but still the same issue. don't worry about it; i got it working via an old rc (so no top priority for me either). i just figured that if i could make this work, it would be helpful to others too... cheers
I can understand why people hesitate to bridge (read: shortcircuit) something they just bought . here is a picture on how to do this (instructions: see above)
yes, and i can send IR codes (see above). i also changed to the serial plugin and tried to send then, but winlirc did not give me an error now (which still does not tell us if this is winlirc, or the ir toy plugin causing the error). for completion, i included the error message, and the config file.
Since the UIT comes "un-cased", I've used an old film roll container as housing. The transparent ones have the advantage that you can see the led responses...
good suggestion. I tried what you suggested, and evt - after several trials/errors - IRRecord suggested to work with the -f parameter. Did that, and (after some more trial/error) got a new config file with RAW codes. Apparently, the Medion RC responds a bit quircky. One has to try with different press-intervalls in order to get your code successfully received. Once done, however, I ran into some issues: 1. since - at that point in time - I could only program the codes from my original remote, I had no idea on how to add the remaining PlayonHD codes (which I have in hex codes) "in RAW" to this config file ?! Anyone knows how to do that (and vice versa) ? 2. in the mean time, I tried to use the RAW config file to see if I could program my Medion rc with this new config file. Unfortunately, WinLIRC loads it without problems, but fails to send any of the codes. I get a "send failed/not supported" message... I thought I could try it with [transmit.exe], but can't seem to work it out? how do you use this program, as there is very limited info available?
HOWEVER: this suggestion did help me out indirectly though. since I could program the Medion with my original N200 remote, perhaps this also works with my old Lidl rc (which I can program via WinLIRC). Guess what: that worked like a charm (well, with lots of tries).
Bottomline: I can now use my Medion with all proper codes programmed. However, I would like to test the new "RAW" config file. If successful, I would upload this file as well as it could help out others with similar problems. Request: can somebody point me in the right direction, meaning: how can I use a "RAW_CODES" config file to transmit codes ?
I tried all sort of things, including plug in/out, etc. Tried afterwards with pin-bridging as well; changing PIDs, etc. Even did a reboot (and reboot after uninstalling drivers/device), disabled UAC, and some more, but noppes... Did even try with a Win XP compatible Command prompt, and Administrator rights. Evt I had to reinstall XP again to reset my UIT. Hence my suggestion to either remove the option in the docs, or explicitly mention the Win 7 install procedure (which probably applies to vista users as well)
Never mind the emtec forum; it's all about the Emtec media players. But I think that my instruction manual would help beginners with a quick start...
normally, you have an additional COMx port in your Device Manager, but no additional HID-compliant device (as one would expect). Fine, as long as it works, right
now, as soon as you press the '$' in the terminal window, windows responses as follows: 1. your COMx port is removed 2. a USB Input device appears, but with failing driver (yellow exclamation marker) (see included image) 3. Windows reports the non-working of the UBS device (via a taskbar message) 4. and your UIT stays "on"; the yellow led indicator remains on.
I tried the -reset command back then, as you suggested as well. But since the device is not enabled/failing, you can not send that command anymore... As mentioned earlier, I did not get this under Windows XP. Even more, if I recall well, even the HID device is shown there as well (along with the COMx port). That's how I found out about the HID device, btw, and the difference in PID between the HID and COMx... As stated: I do not have these problems if you use the "pin-bridging" (at least, in my case)
btw: I'm currently writing a little manual for myself (so that I don't forget for future reference). I also intend to post a 'package of sw/manual' on the Emtec forum site for the guys overthere. The info is not new; it's all out there, one just need to look for it. All I'm doing here is, assemble the appropriate info/sw in one convenient package (for WinLIRC users).
My current Medion Remote Control (no 83388) does not "pick up" any IR codes from the UIT (although I could program my genuine Emtec N200 remote with it). Luckily, I had an older Lidl remote control (URC-L-1870) that worked just fine. I use WinLIRC to send the IR codes.
question: is it possible to get this one working ? use other sw to send/control the codes ? maybe, somehow figure out how the Medion checks for incoming IR codes. I notice that I must press-hold my N200 remote for at least 5-7 secs before the Medion returns a 'Success'. I tried to extend the sending as long as possible, but WinLIRC allows repeats values upto around 45 (if I recall well). Which practically means: sends around 4-5 secs ?!
ps: I'm not using the Lidl remote any longer since some of the (regular) buttons hardly respond any more. it is cheap for a reason
I received my UIT in the beginning of this week, and encountered the same problem: updating fw under Windows 7. Based on this suggestion, I was able to update the fw under Win XP. In this case, I used a terminal sw to activate the bootloader with a $ sign (as suggested in the manual).
However, after some more reading and suggestions, I decided to try out the fw update while bridging the 2 pins. This procedure works fine under Win 7 (strangely enough) ! I tried this first under win XP, but figured that it might work as well under win 7... Reason why I did this tryout: as discussed in length, the "$ activation" can keep UIT in bootloader status; and only a successful fw update releases it again. At the same time, it 'disables' the tool under Windows 7; makes it no longer accessible! And since I no longer work with Win XP (but still had my 'old' Ghost image), I first had to set my pc back to win xp to "free" my UIT again. Doable, but a real pain in the b...
Bottomline: I suggest that the option to activate the bootloader via a terminal should - temporarily - be removed from the doc pages untill a solution becomes available (like - at least - a reset program)
