Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

melmac1982

macrumors newbie
Original poster
Jun 11, 2020
1
0
Hey all, I've just had a disastrous upgrade to catalina...sorted now but I've been using EyeTV with my old elgato EyeTV diversity tuner for probably 10 years now and loved it. I see that there is EyeTV4 which i can purchase through the new developers but a lot of info i've read suggests that it's a bit of a 'downgrade' from the old EyeTV3. There doesn't seem to be a way for me to trial and i'm reluctant to purchase it from what I've read.

Is there any other software out there that I can use on Catalina with my EyeTV Diversity tuner? I don't want to enter into a discussion about streaming etc. Digital TV is great for me here in Australia especially for sport so I'd love to know if it can be done or if EyeTV4 is my only option to work with this tuner?

Thanks in advance!
 
You could try TV Mosaic, I'm not sure it supports your tuner though. TVHeadend probably does but it's a pain in the arse to set up (& it might need a Linux server (can't remember)).
 
I've bought EyeTV4, worked quite well at first then an upgrade made all laggy. Now the forums are showing a security error. I'd quite like an alternative too.
 
I confirm that only EyeTV 4.0.0 8517 runs properly on M1 when watching HD (both DVB-T/T2 and DVB-S). Some minor issues changing channel (has to be done with +/- rather than numbers) and no remote, but I still have it if anyone is interested since Geniatech took it offline - or is it allowed to post it as a dropbox link per MacRumors rules?
 
Just found this thread. I'll have to check out TV Mosaic. EyeTV4 seems to have been a mess since ElGato sold it off. Current state is that the latest version (2 years old now?) doesn't run on Ventura. It crashes looking for /System/Library/Frameworks/FWAUserLib.framework (FireWire Audio, I think), which no longer exists on Ventura. At the very least, it needs to be rebuilt with its internal support libraries updated to not use the framework, which may or may not require some changes to EyeTV's own code, depending how deep in the linked libraries the dependency is expected.
 
Just found this thread. I'll have to check out TV Mosaic. EyeTV4 seems to have been a mess since ElGato sold it off. Current state is that the latest version (2 years old now?) doesn't run on Ventura. It crashes looking for /System/Library/Frameworks/FWAUserLib.framework (FireWire Audio, I think), which no longer exists on Ventura. At the very least, it needs to be rebuilt with its internal support libraries updated to not use the framework, which may or may not require some changes to EyeTV's own code, depending how deep in the linked libraries the dependency is expected.
I copied the "FWAUserLib.framework" from macOS 10.14.6 to Venturas "/Library/Frameworks/".
The framework from Big Sur is missing the required "FWAUserLib.framework/Versions/A/FWAUserLib" that's why I chose Mojave.
Looks/works great so far. As long as no FireWire Audio device is used, I doubt the framework is needed at all, it‘s mere existence suffices. Maybe even a dummy file works…
[EDIT: Dummy file is not working]

Btw, I had a similar experience as @pc297; with all recent EyeTV4 releases I had problems like stuttering and every 2nd frame dropped until Geniatech sent me an old 4.0.0 (8520) which finally has smooth motion again and is stable (EyeTV Sat Free & EyeTV Netstream Sat).
 

Attachments

  • EyeTV4_Ventura.jpg
    EyeTV4_Ventura.jpg
    289.6 KB · Views: 166
Last edited:
  • Like
Reactions: Lycestra
I copied the "FWAUserLib.framework" from macOS 10.14.6 to Venturas "/Library/Frameworks/".
The framework from Big Sur is missing the required "FWAUserLib.framework/Versions/A/FWAUserLib" that's why I chose Mojave.
Looks/works great so far. As long as no FireWire Audio device is used, I doubt the framework is needed at all, it‘s mere existence suffices. Maybe even a dummy file works…
I did get this working (I have VMs for all latest macOS versions since 10.6), tho it wasn't as trivial as putting the framework in /Library/Frameworks/. I also had to use install_name_tool to change the path in the EyeTV binary to look there, and that modification required then I had to re-sign the EyeTV.app bundle adhoc style ("codesign -f -s - --deep"). It runs now, even with USB hardware, but not as securely as Apple would prefer (I don't care too much tho). Did you do anything other than copy Mojave's framework too? Maybe something about your environment has it implicitly check other path locations instead of just the explicit path in the binary (library linkages can be checked by running "otool -L EyeTV.app/Contents/MacOS/EyeTV")
 
I did get this working (I have VMs for all latest macOS versions since 10.6), tho it wasn't as trivial as putting the framework in /Library/Frameworks/. I also had to use install_name_tool to change the path in the EyeTV binary to look there, and that modification required then I had to re-sign the EyeTV.app bundle adhoc style ("codesign -f -s - --deep"). It runs now, even with USB hardware, but not as securely as Apple would prefer (I don't care too much tho). Did you do anything other than copy Mojave's framework too? Maybe something about your environment has it implicitly check other path locations instead of just the explicit path in the binary (library linkages can be checked by running "otool -L EyeTV.app/Contents/MacOS/EyeTV")
Strange. No, it's a fresh Ventura install. Just EyeTV.
I simply copied the framework from "[Mojave]/System/Library/Frameworks/" to "[Ventura]/Library/Frameworks/"
But you're right, according to the error report, if the file is not present, my versions (tested 8520 and 8527) look at several places:
Code:
Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: /System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib
Reason: tried:
'/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file),
'/System/Volumes/Preboot/Cryptexes/OS/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file)
'/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file, not in dyld cache),
'/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file)

That's why I was confident putting the framework in the last directory could work.
I installed the developer tools. No mention of other locations than "/System/Library/Frameworks/FWAUserLib.framework". But no idea where the fallback directories are defined or why it's different for you. This is the output:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)

/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 933.0.0)

/System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia (compatibility version 1.0.0, current version 1.0.0, weak)

/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1555.10.0)

/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 963.200.27)

/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)

/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 158.0.0)

/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 50.1.0)

/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 58286.200.222)

/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)

@rpath/HockeySDK.framework/Versions/A/HockeySDK (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 1882.0.0)

/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 492.0.0)

/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 23.0.0)

/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore (compatibility version 1.2.0, current version 1.11.0)

/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1555.10.0)

/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1670.0.0)

/System/Library/Frameworks/Quartz.framework/Versions/A/Quartz (compatibility version 1.0.0, current version 1.0.0)

@executable_path/../Frameworks/hdhomerun.framework/Versions/A/hdhomerun (compatibility version 1.0.0, current version 1.0.0)

@executable_path/../Frameworks/RTP.framework/Versions/A/RTP (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 606.1.36)

/System/Library/Frameworks/SecurityInterface.framework/Versions/A/SecurityInterface (compatibility version 1.0.0, current version 55109.200.8)

/System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox (compatibility version 1.0.0, current version 1.0.0, weak)

/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate (compatibility version 1.0.0, current version 4.0.0)

@executable_path/../Frameworks/TCMPortMapper.framework/Versions/A/TCMPortMapper (compatibility version 1.0.0, current version 1.0.0)

@executable_path/../Frameworks/ESStreamingKit.framework/Versions/A/ESStreamingKit (compatibility version 1.0.0, current version 1.0.0)

/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 62.1.0)

/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)

/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)

/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)

/usr/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.0.0)

/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)

/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork (compatibility version 1.0.0, current version 974.1.0)

/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 1245.8.4)

/System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage (compatibility version 1.0.1, current version 5.0.0)

/System/Library/Frameworks/CoreText.framework/Versions/A/CoreText (compatibility version 1.0.0, current version 1.0.0)

/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo (compatibility version 1.2.0, current version 1.5.0)

/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
 
Last edited:
This is weird. I notice now the old binary did search in more than just the prescribed location, but it doesn't search /Library like yours does. I have 8526, but that shouldn't matter, I'd think. I even tried moving EyeTV to the /Applications folder in case that caused the linker to treat it differently, but no change.

Code:
dyld[62461]: Library not loaded: /System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib
  Referenced from: <21ECCB56-2844-3FDB-88A0-DB1481AFC8C3> /Users/jpgarcia/Applications/oetv/EyeTV.app/Contents/MacOS/EyeTV
  Reason: tried: '/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file), '/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib' (no such file, not in dyld cache)
zsh: abort      ./EyeTV.app/Contents/MacOS/EyeTV

Edit: side note that I tested this same procedure on an M1 mini, total fail. Even with my modified binary, it doesn't run. In the "Reasons" it listed instead of the file not existing, the signature on the framework was invalid, which indicates to me that there's a benchmark in signing (technique, keys used, or something) that continues to be acceptable to intel macs, but not arm-based macs. So this is a limited solution to be sure. I might try again later by putting the framework elsewhere and signing it adhoc, which other adhoc-signed applications can use.
 
Last edited:
That I have an additional entry is really weird. I use the official 13.0 Ventura and start EyeTV from the GUI.
Works the same for 8526.
Perhaps another (naive) approach: Although in Big Sur the "/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib" does not exist, EyeTV works nonetheless. Maybe there is a way to modify EyeTV so that the same rules from Big Sur/Monterey apply to Ventura?
You're right, although being from Mojave, on Ventura Intel the signature is valid:
 

Attachments

  • FWAUserLib.png
    FWAUserLib.png
    81 KB · Views: 89
Last edited:
That I have an additional entry is really weird. I use the official 13.0 Ventura and start EyeTV from the GUI.
Works the same for 8526.
Perhaps another (naive) approach: Although in Big Sur the "/System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib" does not exist, EyeTV works nonetheless.
Big Sur is a different beast, because the file technically is there if you ask the right subsystem (dyld). One of the techniques that Apple uses to secure the system is to remove the linkable binaries from the system, like the file you mention, and have the dyld linker link apps to a system cache file. Faster and, since the boot volume is signed and read only, very consistent machine-to-machine already. It still works the same if you work thru dyld, which Python now has to do as well, instead of looking for a binary object to link directly as it had done until almost just before Big Sur came out. Similarly, the SDKs that developers link to no longer hold binaries either since 10.11, and instead have a text symbol table "tbd" of the same name as the library, which the compiler is happy with and the actual runtime will be there when it executes.
 
  • Wow
Reactions: arw
@Lycestra: Well, it'd still be interesting to know why your instance doesn't look in "/Library/Frameworks/".
I'd just like to understand what is currently different on my system just in case it breaks with a future update.
Out of curiosity I changed the path in the binary with "hex Fiend" but then code-signing fails. Guess I have to try "install_name_tool".
 
Last edited:
The two commands I had to use are the following. They 1) change the linking path and 2) re-sign the app bundle ad-hoc. The framework could be anywhere, and one of my ideas was to put it inside the EyeTV.app bundle in its Frameworks folder and use the relative linkage path @executable_path/../Frameworks so it follows along. Re-signing the bundle should allow that.
Bash:
sudo install_name_tool -change /System/Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib /Library/Frameworks/FWAUserLib.framework/Versions/A/FWAUserLib /Applications/EyeTV.app/Contents/MacOS/EyeTV
sudo codesign -f -s - --deep /Applications/EyeTV.app

edit update: Works on M1 in Ventura now as a result of putting the framework in the bundle and re-signing it, since it overwrites the official signature in the framework that M1 doesn't accept.

edit 2: it would be nice to know why one machine searches there despite the explicit path and another doesn't. could be an environment variable (check using "env") or some developer additon.
 
Last edited:
  • Love
Reactions: arw
At this link on the EyeTV forums there is a post by delacroix headed "Problem Solved". It contains a link to an EyeTV4 build that works under Ventura confirmed by me and a number of other users. I found this after trying unsuccessfully the types of fixes suggested here.
 
  • Like
Reactions: DaPhox and arw
At this link on the EyeTV forums there is a post by delacroix headed "Problem Solved". It contains a link to an EyeTV4 build that works under Ventura confirmed by me and a number of other users. I found this after trying unsuccessfully the types of fixes suggested here.
the script they started with looks like binary blob hacking, which is why it requires a specific version to modify, vs using xcode tools to alter the binary headers with precision and codesigning (adhoc is not really signing as much as just a hash to detect modification). To each their own, tho I agree with the other users that show anxiety about downloading the binary from the outside link.
 
The framework could be anywhere, and one of my ideas was to put it inside the EyeTV.app bundle in its Frameworks folder and use the relative linkage path @executable_path/../Frameworks so it follows along. Re-signing the bundle should allow that.
Interesting approach! With "install_name_tool" it worked as you described (Intel).
Version also 8528 works, but it's good to know I can modify my proven version to run on Ventura.

it would be nice to know why one machine searches there despite the explicit path and another doesn't. could be an environment variable (check using "env") or some developer additon.
It's a vanilla Ventura fresh from the installer.
user@user's MacBook Pro ~ % env
__CFBundleIdentifier=com.apple.Terminal
TMPDIR=/var/folders/lv/*****/T/
XPC_FLAGS=0x0
TERM=xterm-256color
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.upIjUuOKyU/Listeners
XPC_SERVICE_NAME=0
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=447
TERM_SESSION_ID=*****
SHELL=/bin/zsh
HOME=/Users/user
LOGNAME=user
USER=user
PATH=/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
SHLVL=1
PWD=/Users/user
OLDPWD=/Users/user
LC_CTYPE=UTF-8
_=/usr/bin/env
 
Last edited:
I copied the "FWAUserLib.framework" from macOS 10.14.6 to Venturas "/Library/Frameworks/".
The framework from Big Sur is missing the required "FWAUserLib.framework/Versions/A/FWAUserLib" that's why I chose Mojave.
Looks/works great so far. As long as no FireWire Audio device is used, I doubt the framework is needed at all, it‘s mere existence suffices. Maybe even a dummy file works…
[EDIT: Dummy file is not working]

Btw, I had a similar experience as @pc297; with all recent EyeTV4 releases I had problems like stuttering and every 2nd frame dropped until Geniatech sent me an old 4.0.0 (8520) which finally has smooth motion again and is stable (EyeTV Sat Free & EyeTV Netstream Sat).
Hello,
I have the problem with stuttering and dropped frames on Catalina. I found this thread, and I contacted geniatech some weeks ago, but they never replied. So are you willing to share 4.0.0 (8520)?
Thank you
 
Hello,
I have the problem with stuttering and dropped frames on Catalina. I found this thread, and I contacted geniatech some weeks ago, but they never replied. So are you willing to share 4.0.0 (8520)?
Thank you
Out of curiosity, have you tried the latest one (8528 for Ventura)?
However, I've sent you Build 8520.
 
  • Like
Reactions: pc297
Out of curiosity, have you tried the latest one (8528 for Ventura)?
However, I've sent you Build 8520.
Thank you so much for 8520, it just works!
8528 is the same trash as all the other versions , stuttering dropped frames, not usable at all
 
  • Like
Reactions: arw
Out of curiosity, have you tried the latest one (8528 for Ventura)?
However, I've sent you Build 8520.
I am interested too! Only 8517 works for me but it's pretty beta... Thanks in advance!
 

it looks very much as if these products will no longer be developed further.

They look unmaintained.

Or am I wrong?

Looks like crap from 10+ years ago
 
it looks very much as if these products will no longer be developed further.
They look unmaintained.
Or am I wrong?
Looks like crap from 10+ years ago

So per the title of this thread, do you have a viable alternative to suggest?

While I agree with you that they're not very good at maintaining their software, are there any specific problems you are having?
The changelog to their latest version #8532 at least states "Compatible with macOS 14" (which is Sonoma).
https://www.geniatech.eu/download/eyetv-4-0-0-8532-64-bit-mac-version/
 
Last edited:
Thank you so much for 8520, it just works!
8528 is the same trash as all the other versions , stuttering dropped frames, not usable at all
Just a quick update. I used OCLP to upgrade my MacBook 2012 from Catalina to Sonoma. And with Sonoma, the latest version works perfectly. MacBook 2012 with Catalina has the stuttering issue, but version 8520 works perfectly.
 
  • Like
Reactions: pc297 and arw
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.