Android Mattrix KODI Image - V3.2 - 08/12/2015

296 99615
dlanor  
Adromir replied at Thu Nov 13, 2014 15:19
I am trying it out right now, seems to be a bit unresponsive to me, but maybe its because of the fir ...

Some lost responsiveness is unavoidable when raising the true rendered video resolution.
1080p has the same aspect ratio as 720p, so both horizontal and vertical size has increased by a factor of 1.5.
This means that the total amount of pixels per screen (and per same-sized object) has increased by a factor of 2.25.

So the amount of screen rendering work required by CPU and GPU has also increased by that factor of 2.25.
And that naturally leaves less CPU time for other processing, including the needs of 'general responsiveness'.

You simply have to choose your preferred balance between response speed and video resolution.

Best regards: dlanor

dlanor  
Edited by dlanor at Fri Nov 14, 2014 19:21
Adromir replied at Thu Nov 13, 2014 16:23
Did you stripped it of the language files? Whenever I try to change the system language, the setting ...


I haven't tried to change system language, but I have changed the keyboard layouts from the original English to Swedish, and that worked fine both for the virtual keyboard and for my external Rapoo keyboard (connected wirelessly through its USB RF receiver plugged into a 4-port hub which is plugged into a BPi USB connector).

----- Some experiments later -----
After starting this reply I now went back to the BPi and tested switching the system language to Swedish (shown properly as "Svenska" in the menu), and this too worked fine. So I think you must have some problem specific to that SD card or to its flashing with this Android image. Badly flashed cards are a common source of problems.

Btw: That 'Rapoo' Keyboard is part of a mouse+keyboard combo with both parts communicating through the same USB RF dongle. And this is the only such combo which I've found to work with my BPi. I've had another RF-connected keyboard, and several different mice, but no similar combo (the others I've tried all fail to be recognized by BPi Android 4.2).

Best regards: dlanor

mattrix  
Thanks dlanor

I can actually change the resolution via command line.
So, I will make a single image, which can easily be changed between 720 / 1080 by looking for a file

/sdcard/Android/data/Mattrix/enable1080  
etc

If this file is present, it will set the screen to 1080p.
I orignally had this - but wasn't sure on a good DPI.
But, I like your suggestion.

I think this latest Kodi isn't the great.
Might revert to the Alpha4 I originally used.
It was a lot quicker in the 1080p.

SMB is a bit of a pain.
To test it here, I was just playing SMB videos via the XBMC filemanager.
Maybe paths for scanned files is different...
Also, it's not going to work for password shares.

As for the "fixing mobile issue":
In my old image, if you click "Mobile networks" it would fail.
This was due to me removing the phone.apk.
It has nothing to do with WiFi

dlanor  
Edited by dlanor at Fri Nov 14, 2014 23:49
mattrix replied at Fri Nov 14, 2014 22:17
I can actually change the resolution via command line.
So, I will make a single image, which can easily be changed between 720 / 1080 by looking for a file

/sdcard/Android/data/Mattrix/enable1080  
etc

If this file is present, it will set the screen to 1080p.
I orignally had this - but wasn't sure on a good DPI.

DPI choice can be tricky. Essentially what looks good and readable with a given DPI in 720p will need that DPI multiplied by 1.5 for use in 1080p with same appearance. But this rule is complicated by the fact that some apps have preconceived ideas of their own, such as using font rendering methods which fail when DPI is too low.

For example, I consider a DPI of 180 to be a good compromize between readability and a good number of objects per screen for 1080p (decent browser pages, and Plex client screens), and for 720p this corresponds to a DPI setting of 120, which is what I'm currently testing. But this causes the supplied launcher to cut off the bottom pixels of all the text titles of apps on the desktop. I do not see any similar cuts in other apps however, and since I've installed the Nova launcher it doesn't matter how the old launcher would render the titles. (But of course there may be other apps using similar bad rendering methods.)

I think this latest Kodi isn't the great.
Might revert to the Alpha4 I originally used.
It was a lot quicker in the 1080p.

For me the main problem is that the latest ones lose backwards compatibility with skins made for Gotham, so this will apply to ALL newer versions to come as well, at least until someone ports the needed XBMC skins to Helix Kodi (if that ever happens).

SMB is a bit of a pain.
To test it here, I was just playing SMB videos via the XBMC filemanager.
Maybe paths for scanned files is different...

That's what I was doing too. I never scan files for the XBMC 'library', since all my 'library' type needs are handled through Plex.

So I either play files scanned by Plex, which works fine through the PlexBMC addon, or else I play files not scanned at all, through normal SMB fileshares, which works fine when browsing the files with 'ES File Explorer' to pass the files on to 'MX Player', but never works when trying to do it through XBMC/Kodi. But from what you said in your reply I now understand that this is probably an authorization issue. (More on that below.)

Also, it's not going to work for password shares.

I agree that it doesn't work as-is, but I disagree in the sense that it definitely would work if the access links were handled properly by XBMC.
(In the same way they are handled by 'ES File Explorer', which has no problems invoking 'MX Player' with SMB links.)

I always use password protection (in my LAN nothing is shared for anonymous access), and for that reason I naturally include username and password for each XBMC source path defined. This being the case XBMC is aware both of the passwords needed and the fact that their use is required (due to their very presence), so for proper access the username and password MUST be included in the access link passed to an external player, in order for that player to be able to gain access to the fileshares. I'm fairly sure that this is exactly what the XBMC/Kodi programmers have neglected, which makes it impossible to use external players for XBMC in a LAN with decent access security.

Btw: I have tested that this bug stretches far back in time, long before the first Kodi alphas, so reverting to older versions would not fix this.
But I will still revert to a slightly older version, so as to regain compatibility with the PlexBMC-supporting skins.
That is the top priority for me, as I have a lot of media handled by my Plex server (somewhere around 16 TB at present).

Best regards: dlanor

mattrix  
XBMC will only be sending the smb path without the username password.

This looks promising
http://forum.kodi.tv/showthread.php?tid=155526&page=2

dlanor  
Edited by dlanor at Sat Nov 15, 2014 01:33
mattrix replied at Sat Nov 15, 2014 00:13
XBMC will only be sending the smb path without the username password.

Yes, that was my conclusion too.


I agree. That method should compensate for the XBMC bug of not passing the authorization parameters.

Best regards: dlanor

dlanor  
Correction: That method would have worked, but that app has apparently been abandoned in favor of the one that doesn't work for authorized SMB.

Reading the linked thread more closely, it is now clear that the SMBWrapper app is an older product by that site's member "birdyisme", who had the right idea about passworded access, but whose implementation was limited to SMB only. The other site member "Xmister" then made his own app with features extended to cover other protocols than SMB too, but in so doing he completely missed the point of implementing passworded SMB access, and in his last post in the XBMCWrapper thread (from mid-September this year) it seems as if he's not really clear on how it was originally implemented (he states that it's not possible !!!)

We may still be able to make use of the best features of both, but this must be done by replacing the playercorefactory.xml file after installing and configuring both of the XBMCWrapper and SMBWrapper apps separately, since both of them will replace any existing such XML file with their own... So after that mayhem it will be necessary to replace what they did with a playercorefactory.xml file edited to use SMBWrapper for SMB protocol only, and use XBMCWrapper for the other protocols it supports.

Best regards: dlanor

mattrix  
Trying the new "old" version now.
I like it. Quick and none of that white "loading" screen.
Straight into MX Player.

Looks to me like it supports all the same protocols.
As, when you use it to install the playercore, it puts itself as handler for rtmp, smb, etc

Uploading a new image now with the new "old" wrapper and also XBMC Gotham.

Will PM you the link so you can give it a ago
Tried with a password protected SMB share and seemed to work fine.

mattrix  
Did you want to try this image

DOWNLOAD

It is using that new wrapper and XBMC Gotham stable

dlanor  
Edited by dlanor at Sat Nov 15, 2014 06:16

I'm downloading that v3.1 image right now, and will test it a bit later. I was up all night and it's now past noon again, and I'm not sure how long I'll keep going before I need to sleep, so it may have to wait until tomorrow. I've been looking into that new/old SMBWrapper myself, and have realized that it obviously can't be used as-is with Kodi, since Kodi has its settings stored in a differently named folder tree, so SMBWrapper would neither be able to find the password info nor create its playercore file. The latter could of course be patched by hand (for combination with XBMCWrapper that would be required anyway), but the password info is a showstopper.

So until someone recompiles SMBWrapper it can only be used with Gotham versions (though early Helix versions may have used the old folder tree).
But I think the SMBWrapper sources are free, so making a real Helix-Kodi version should be possible, or even one compatible with both XBMC and Kodi.

Btw: Have you noticed how the "Basic Settings" tab of DragonFace always shows the same incorrect resolution for each image, of 800x480 pixels ?
This can be changed to reflect the true resolution, by changing two parameters in the "System configuration" editing of "sysconfig1.lhs".
lcd_x                   = 800
lcd_y                   = 480
Setting these to the proper screen width and height will cause DragonFace to show the correct values when next loading the saved image.
I'm not sure if these values are used in any way by a running Android system or its apps, but those values are clearly intended to represent the true resolution, even though their names seem specific for LCD display. But that's only natural considering that the original image was intended for an LCD tablet. I have patched them accordingly in some of my tests, and have not seen any ill effects from it. But I'm not sure if it's done any good either, so their use may be redundant.

Btw 2: I almost forgot to mention that I managed to find newer versions of PlexBMC and a related Amber skin which work well with Helix-Kodi, though Gotham-XBMC still  is the better choice for us now, assuming that SMBWrapper works out as intended with it.

Best regards: dlanor

You have to log in before you can reply Login | Sign Up

Points Rules