Very odd, so one display with the correct property readout (index 0) out but not working
Not sure why at this point but will dig around in the code a bit
Beiträge von Rick164
-
-
Dxdiag and config looks fine, same hardware setup I had last month (GTX970) as well so can rule out any issues there
Below is a new build which will output all displays it can find to the debug.log including their indexes, also a few other things to try:- System DPI is currently set to 144 DPI and while I don't suspect this can interfere with capture would try it with 100% (no upscaling)
- Would try english language / locale, while unlikely we can then rule that out as well.Download link for debug build:
-
That invalid call usually means it can't read the DirectX surface (failed to attach), if it's only one monitor at index 0 it should have worked.
Could you post your config and hardware specs + used OS, only tested here on gtx900/1000 series and intel IGP (HD520) on Windows 8.1 / 10 so far but worked right awaySome other process might also be claiming exclusive access (game / directx interface) but that is pretty rare.
-
Another thing to try is to clear all priorities via the app or hyperion-remote, because maybe another process (Kodi for instance) is claiming access with a higher priority
Will double check the priority code in case it's hard coded but believe that was migrated from AtmoLight correctly. -
Maybe it can't read out the surface for some reason but it should report an error then, might be that you set it to the Hyperion JSON port instead of the ProtoBuffer port.
Both will connect but only ProtoBuffer port (19445) will work so worth double checking -
Not easy to debug yet but you do have multiple notifcation level options for the config:
No messages
<add key="notificationLevel" value="None"/>All messages both debug and error
<add key="notificationLevel" value="Info"/>Only error messages
<add key="notificationLevel" value="Error"/>Uploaded version which has Info notifcation level in config and will also write a debug.log file to the app location:
-
Think we need to add some proper fallback and auto-detection for monitors and include those in an UI as well for manual selection, bit busy with work but added to to-do list for enhancements and will get around to it early next month
Right now it can't always get the right D3D surface for multi-monitor setups which results in that error as there's no info for it to read back, looked at SharpDX which might be a good alternative as well. -
Multi-monitor can be a bit buggy with the SlimDX library used in this, the monitor index in config should work however with multiple adapters (IGPU + dedicated) and AMD I've seen detection being off (detecting incorrect surface).
@Doc.Ex thanks for reporting the issue, corrected the default delay to 10ms as I indeed mixed the two up so pushed new release
Will improve auto-detection in a later release so that delay is based on refresh rate. -
Lijkt me inderdaad een goed plan, anders is er altijd nog een alternatief zoals OpenElec of Rasplex
-
Yep recent getest hier onder Raspbian en deed het, voorheen stond er op de wiki dat dit niet werkte maar lijkt inmiddels verholpen te zijn.
Beste is hier op het forum maar dan in het Engelse gedeelte , HyperCon staat wel op de lijst voor een redesign maar wanneer dit afgerond wordt is nog niet bekend. -
Oh dat verklaard het, de addon maakt het wat fijner want dan stuurt ie gewoon je image data vanuit Kodi door naar Hyperion ipv desktop capture intern
Yep zou ook geen verschil verwachten eerlijk gezegd tenzij er een andere parameter meegegeven wordt vanuit HyperCon. -
Het kan zijn dat je niet de officiële addon gebruikt in Kodi maar helaas niet veel ervaring met OSMC hier, zou de Kodi Hyperion addon daar even deinstalleren en dan opnieuw installeren bij Kodi via deze zip:
https://github.com/hyperion-pr…perion/archive/V1.0.2.zip
Framegrabber zou normaal gesproken niet nodig moeten zijn dus dat is wel vreemd, de installatie loopt inderdaad stuk op de deps dus vermoedt dat iets in de package manager niet lekker zit of dat het script deps verwacht die onder OSM niet (meer) beschikbaar zijn.
-
Working here on Windows 10 x64 so should work (GTX1080 + 368.39 drivers):) , on multi monitor setups you do have to supply the monitor index if the screen you are capturing is not the first one (primary).
Also make sure to use the latest build:https://github.com/RickDB/Hype…1.2/HyperionScreenCap.zip
Failed to capture usually means it can't get the surface so would play a bit with the monitor index.
-
Network lag isn't noticeable on LAN at least, the only lag is during the surface back buffer copy which is 1-5ms depending on hardware but for 60FPS that is still plenty fast
-
In principe niet nee want is alleen voor desktop capture op de RPi
-
Welkom :coffee:
Het zou de framegrabber kunnen zijn of lokale hardware storing maar als het alleen software herinstallatie is geweest is dit onwaarschijnlijk.
Zou het volgende in de config uitzetten en dan opnieuw testen -
If it happened out of the blue it probably means there's a hardware issue, possibly you are drawing more than allowed out of the usb port (maybe higher load today?) so would try with an powered usb hub if you have one around
-
Yeah would remove it but maybe we can keep a legacy HyperCon version around just in case people need to re-config their ambiled setups while still on their old firmware
-
Not sure but could check if Qt5 didn't get installed with those other deps (Qt5-default I believe for wheezy)
-
It should not be able to compile with Qt4 though as that function was added in Qt5.0
Qt4 (no ipv4 option)
http://doc.qt.io/qt-4.8/qhostaddress.htmlQt5 (ipv4 added)
http://doc.qt.io/qt-5/qhostaddress.htmlMaybe that machine already has both libraries?