Hello everyone,
I’m testing the latest Kodi 17 beta build on my first generation Apple TV, but I’m having some troubles using a white Apple TV remote (A1156).
The remote works perfectly with the latest stable version of OSMC; however in the beta version pressing the buttons does not have any visible effect on the UI. I can’t navigate in menus, nor scroll up or down or perform any other action.
Button presses are registered by the device, as the front led blinks orange every time I press a button; also running atvclient manually from terminal correctly shows all key presses. The UI however is not updated accordingly, as if it was totally ignoring the commands.
Navigation is fine using a USB mouse or keyboard. I’ve tried going into MyOSMC → Remotes and selecting again the profile for the white Apple TV remote, but to no avail. I’m not sure if it’s the expected behavior, but the “peripherals” section in Settings → Input is grayed out.
The system has been freshly installed and updated using dist-upgrade as suggested.
I’m attaching the log immediately after boot: http://paste.osmc.io/ihiniyohiy
I tried here with an AppleTV on Krypton and can’t replicate this.
Your logs aren’t debug logs, so I can’t see anything there.
Unfortunately there don’t seem to be (m)any testers of Kodi Krypton for AppleTV, so I will likely have no option but to drop support for the device soon. Feedback is really important but I have yet to receive any re. CrystalHD performance etc.
Sam
Hello Sam,
thanks for the prompt answer. I really really appreciate your efforts on this port, please don’t drop it! I just discovered today that the Krypton beta was out, otherwise I would have updated sooner and I could have given you more feedback.
Performance is actually surprisingly good. Sometimes during menu navigation the frame rate drops under 20, but for the most part it’s in the 40 to 60 fps range. Crystal HD is recognized and works absolutely flawlessly up to 720p, for what I’ve tried.
The only issue is this one with the remote. By the way, I tried using a different Apple TV remote (just to rule out any possibility), but the problem remains. If I install the stable release, instead, the remote works just fine.
I’ve now enabled debug mode and I’m uploading new logs, are these in the format that you need?
I’m more than willing to do everything I can to help testing!
Just in case, is there a different way to install the test distribution (like a normal OSMC image) other than to perform an update, to rule out problems with the update procedure?
http://paste.osmc.io/ojuyemocev
EDIT: Just a thought. I noticed that atvclient has been updated on its GitHub page to explicitly support Krypton. Does the OSMC test build contain this update?
Hello Sam,
I can confirm the issue is effectively with atvclient.
I followed the build instructions of atvclient directly on the Apple TV via ssh and now the remote is working beautifully!
I’m not entirely sure of how the testing process works, could it be that the test binaries for Kodi 17 do not include atvclient (which is consequently not updated)?
As a reference, this page got me in the right direction; to compile the binary on an Apple TV, it’s also necessary to perform apt-get install libusb-dev to install the necessary libraries, and to move the atvclient binary from /usr/local/sbin/atvclient to /usr/sbin/atvclient overwriting the existing one.
On a side note, since we’re talking about feedbacks: there are a few UI glitches in the Settings->System Settings menu, in that the screen flashes randomly with colors. This does not happen in any other menu that I’ve tested so far.
Thanks again for the wonderful work, please keep supporting this platform!
EDIT:
About the CrystalHD performance, I’ve done a few more tests now that the remote is working. MP4 at 720p seems to work fine; MKV at 720p has some very occasional lags (nothing too noticeable, it may be that decoding MKV is asking too much). At 1080p things start to stutter significantly and become mostly unplayable, but I guess that’s just a limit of this ancient platform, even with the CrystalHD hardware acceleration. I haven’t verified whether these slowdowns are specifically new to Krypton or if they were already there with Jarvis.
As a reference, I’m testing the system using Kodi predefined new UI, not the new OSMC UI (which I tried, but seems to be too slow on this machine).
Which skin are you using? Can you check the GPU’s internal temps? Artefacts unfortunately usually suggest the 7300M is about to kick the bucket.
It seems we have a fair few aTV users from the Crystalbuntu era, but few seem to be willing to test or participate on the forum. I will have to weigh up the amount of time spent on supporting this device vs working on other parts of OSMC. There’s a lot of low hanging fruit, i.e. easy improvements to playback etc that can be made to improve aTV performance, but I really do struggle to find users willing to provide feedback. Time will be spent where users are able and willing to test and improve things.
Perfect. Updated, and built.
Try running the following commands in an hour.
apt-get update
apt-get dist-upgrade
That would be good to know. Also good to know which card you have.
Sam
Hi Sam,
I’m using the Estuary skin. Seems to work fine, with the exception of the system settings screen.
Just to clarify, I do not experience artifacts or visual glitches or parts of the UI which are colored differently; it’s just that when I open the System Settings menu, the screen flashes a couple of times (like red / yellow) for a fraction of a second and the stabilizes. There are no artifacts in playback. Also, I recently replaced the thermal pad of the 7300M, so I think the GPU is fine and I’m more inclined to think of this as some sort of software glitch, perhaps related to the fact that the first sub-menu of the System Settings is the display menu and that I’m using a quite old crt TV. There are no similar issues under Jarvis. By the way, related to this, would you suggest to keep the Apple TV on all the time or to shut it down when unused?
Is there a way to check the Crystal HD model via software without having to open up the box?
When I get back home tonight I’ll try to remove the atvclient that I compiled and to perform the update from apt to check if the rollout was successful. Also I can probably install Jarvis on a USB stick and perform the tests you have asked for regarding the performance of Crystal HD under the two Kodi versions.
Thanks again for your efforts, if there’s something else I can test I’d gladly provide feedback!
dmesg or lspci (need pcituils)
Thanks, that will be great to confirm
Installed lspci, seems like I have the BCM70015 version. This is the output of lspci:
02:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video Decoder [Crystal HD]
And the output of dmesg:
[ 6.560688] crystalhd 0000:02:00.0: Starting Device:0x1615 [ 6.560702] crystalhd 0000:02:00.0: enabling device (0000 -> 0002) [ 21.783990] crystalhd 0000:02:00.0: Opening new user[0] handle [ 22.480505] crystalhd 0000:02:00.0: Closing user[0] handle via ioctl with mode 417a00
I can confirm that the updated distribution includes the correct build of atvclient.
I have removed my own binary and performed your commands, and the remote is working just fine.
I have also performed some extensive performance tests, and I can report that Jarvis performs consistently better than Krypton while playing HD content.
In particular, while 720p performance is almost on par (but still a little lagging on Krypton), 1080p is no match - Jarvis is able to play 1080p content, both in MP4 and in MKV, with zero issues, while Krypron stutters significantly to the point that it’s basically unwatchable. I have noticed that Krypton starts playing sooner than Jarvis.
Thanks for confirming.
BCM70015 is the latest (and best) version of the CrystalHD card.
It’s likely related to the fact that Kodi Krypton uses the new VideoPlayer. CrystalHD code is quite old, and isn’t really adapted for this. I’m still undecided whether it’s worth investing further time in this.
Try using a lighter skin (Confluence) to see if resource constraints are problematic.
A full set of debug logs when playback is problematic may give some clues.
Hello everybody,
sorry for not having replied promptly, but I’ve been having some personal troubles in the last week that have prevented me from performing further testing.
I will give a try to using Confluence. As for the debug logs of the playback, what options should I exactly turn on and how can I grab them?
It’s well documented in our wiki.