UnixGuy

Good catch!! You are correct, there should NOT be a space between the forward slashes.

It often happens to me that I think I saved a change but actually didn't. Or I copied the original file from a different place, but I forget to copy the changed file, or something else like that. Do macmini:Scripts earlnoe$ cat getepg which prints the file getepg, just before macmini:Scripts earlnoe$ ./getepg which executes it, to make sure you are executing with the change.

https://stackoverflow.com/questions/2841593/bash-script-bad-interpreter There is a similar error discussed at the above link. From that discussion, it appears likely that you first created the script using a Microsoft text editor, and then cut and pasted the result into the TextEdit window. The problem with that approach is that the MS Office software puts all kinds of invisible funny characters into their documents. In particular, Microsoft uses a CR/LF combination where the Mac just uses a CR. (And Linux uses just a LF.). Instead of cut-and-paste, try manually typing each of the characters into the TextEdit window. As Wisconsin Eric mentioned, plain text is essential. You never know what invisible characters might be lurking in a document!

It sounds as though it is the contents of getepg that is now bad. Is there perhaps a cd command in the getepg file?

If it were my system, I would try adding the preference by doing defaults write com.elgato.eyetv "poll for HDHomeRun" 2 but I can't guarantee what the result might be. One can also delete a preference by doing defaults delete com.elgato.eyetv "poll for HDHomeRun" Also doing man defaults will give the manual information for the mac defaults command.

By the ">" I just meant the terminal prompt, so don't type that. If typing defaults read com.elgato.eyetv "poll for HDHomeRun" returns no result, then I would guess that preference is missing entirely. Try typing defaults read com.elgato.eyetv > defaults.txt which should save ALL of your EyeTV preferences into a file named defaults.txt, which you can open with a text editor and look for HDHomeRun.

I'm curious to know what the terminal command > defaults read com.elgato.eyetv "poll for HDHomeRun" would yield on a build beyond 7521? (This reads the EyeTV "poll for HDHomeRun" hidden preference.) On my pre-7520 build, it has the value 2. Maybe being able to see HDHomeRun is a settable hidden preference that is just turned off in the later builds? If so, it might be possible to turn it on again with the mac "defaults write" command. A guy can hope...

See post 4 in this thread: https://eyetvforum.com/index.php?/topic/2048-eyetv-369-7521-for-mac-does-not-include-hd-homerun/&tab=comments#4 Claire from EyeTV support confirmed that they dropped support for HDHR after 7521. So even if there is a 64-bit upgrade, the HDHR tuners won't work. I wish Silicon Dust had bought EyeTV from ElGato!

It has been reported in a number of places, including the Silicondust forums, that HD Homerun tuners are no longer recognized by EyeTV for builds after 7520. Whether that applies to all HD Homerun tuners, or only some of them, is unclear.

Yes, they are different. I'm wondering if that is somehow related to the email--not problem, though, if the same email address is used.

This is discussed in some of the other topics. Look for ones with recent posts---pretty much all of the recent posts are on this subject.

Has anyone requested the Open Source code as offered here? https://www.geniatech.eu/open-source-compliance-information/ It's not clear what part of the EyeTV code is included here. I was thinking that if we could see the source code that is trying to do the download/update, we might understand better what is going wrong. I have tried to monitor the download interaction, and it is definitely communicating with a server in Germany, and is receiving packets. The packets are encrypted so I can't see what the computers are saying to each other, but the local EPG database is being changed in some way. (The file date is changed.) The type of error I get on a download has changed. It used to be during "Adding Programs" (though no programs were actually added). Now it is during "Parsing..." The Mac Console information shows a memory leak occurred. Perhaps this is some technical issue after all, although I wouldn't hold my breath waiting for a fix! I tried switching to the GraceNote (European) server in the preferences (instead of TV Guide). Curiously it showed me as having an active account even though my account is with TV Guide. I tried updating, and the process finished with no errors. No new programs showed up in my guide, but then I don't have any European channels. This whole episode is weird.

/getepg is an entirely different location than ./getepg The first is in the "/" directory (the directory above /Users) The second is in the "." directory (i.e., the current directory). If the missing dot was just a typo in your post (and not the source of the error), then please disregard this.

In the following, I am writing % for the prompt in the terminal window. Try this: % cd ~/Scripts Note that ~ is an alias for the home folder. You could also try this % cd ~ ; ls which will list the files and subfolders of your home folder, or this % cd % find . -name getepg which will search for a getepg file starting at your current folder (which will be your home folder after the cd).

Another way of automating the process to run it on a daily basic is to use an EyeTV Triggered (Apple-)Script. on RecordingDone(recordingID) tell application "EyeTV" set myid to (recordingID as integer) set mytitle to get the title of recording id myid end tell if mytitle contains "UPDATE_EPG_NOW" then do shell script "Users/Bill/getEPG.sh" end if end RecordingDone Then schedule a one minute manual recording with title "UPDATE_EPG_NOW" that repeats every day.

I had a similar problem. In my case, I thought it might be because I had signed up before but forgot the password. However, the email to reset the password never arrived, and setting ip a new account didn't work either, until I used a new email address. In my case, the second one I tried worked.

One possibility is that Mojave is natively 64-bit, and is running 32-bit applications like EyeTV in a 32-bit compatibility mode, perhaps using a 32-bit virtual machine. That it, it may be simulating a 32-bit machine, which would inherently be a lot slower. Try using a lineup with only a few channels and wait a really long time before assuming the machine is frozen. If it eventually finishes, you know it is some efficiency issue and you can try to address that.

One of the previous posts said that mc2xml will not work with MacOS 10.6.8 (Snow Leopard). Is this really true, and is there no way around it (short of upgrading the MacOS, to Lion, which I would rather not do)? This is the main reason I have not tried SchedulesDirect.

Yes, I think you may be onto something there. It is when new stuff is introduced that the old stuff is obsoleted. Or it may break if there are software upgrades. I'm also wondering if the project to upgrade EyeTV to a 64 bit program might have something to do with it. https://www.geniatech.eu/blog-8-eyetv-32-bit-macos-highsierra-10-13-4/ In trying to make TV Guide work with a 64-bit version of EyeTV, they may have broken access by the 32-bit version. Lots of things would be different with 64-bit data. At least this would mean Geniatech are still actively developing EyeTV.

I'm trying to pin down precisely where the failure occurs. If the server were simply down, it would be a different type of error. The server appears to be up and running and taking connections, but seemingly sending no data. Out of curiosity, I would like to be able to see what URL and port the client is connecting to, what TLS handshake is occurring, what http or https POST or GET commands it is sending, what data or error code the server is sending in reply, and whether the client is registering a timeout. These might provide some insight into whether it is a technical problem or a license problem.

When I click on 'Update Now' the EyeTV software seems to successfully connect to the server, and goes to the 'download data' step. Sometimes the ostensible download goes on for a long time (which suggests it might actually be downloading something, or it may have some kind of variable timeout setting). Then it goes to the 'adding programs' step. This is where it fails with 'update failed due to server error.' I wish there were some way of tracing the actual internet connection to see what is happening. My Mac Mini is running the older Snow Leopard MacOS 10.6.8, and I don't think I can do that. Maybe some later OS can.

topic/2512-gracenote-has-no-informations-after-january-2nd/ Apparently the Gracenote server in Europe had a similar problem where the listing ran out by Jan2, 2019, but it was apparently fixed on Jan 3, at least for manual updates.

Thanks for the instructions for getting lists from the xmltvlistings.com site. I generally followed them and they worked for me. However, I had a few differences. I left the server setting on TV Guide instead of resetting it to none. In the Channels window, after an initial download, I switched only my favorite channels to xmltv using the dropdown menu. I didn't save anything, channel lineup or otherwise.. However, even if I quit and reopen EyeTV, my changes seem to persist. The download did populate the listings window for the channels that were switched to xmltv. For convenience I also created a EyeTV script as described in the EyeTV Help guide. This is actually an AppleScript so I used the AppleScript editor (in Applications/Utilities) to construct it. All it does is execute the unix shell script described by the previous post. (Thanks again!) To build it, just type something like do shell script "/Users/Bill/scripts/getepg" into the AppleScript editor window, and save it with some name like getupdate. The AppleScript editor will give the file an extension so the full name will be something like getupdate.scpt in the folder where you saved. For EyeTV to see it, it needs to be moved to a /Library/Application Support/EyeTv/Scripts/ folder, which must be created if it does not already exist. Also EyeTV must be quit and restarted for the scripts menu to appear (as a funny symbol between the Windows and Help menus on the main menu bar). This is probably irrelevant if the download process is automated, but it is nice to be able to invoke an update from directly within EyeTV.