|
|
@mattrix:
I've spent a few hours testing the new 1080p image you made, though I modified it a little myself first, simply to increase the data partition to 4 GB and the system partition to .75 GB. (Original values being 1 GB and .5 GB respectively.) I had no problems booting or configuring the system, so I have no complaints about its basic functionality.
After changing the hardware output mode to 1080p I can verify that this system uses true 1080p resolution (unlike some other attempts which only change hardware mode). Some users probably miss doing this, leading to complaints, as they then get the rendered 1080p screen re-rendedered as 720p to fit the output mode, which wastes hardware resources and makes small sized text garbled (as shrinking eliminates some pixels). Another important setting is the 'Screen trimming', which by default reduces the physical size to something far less than 1920x1080, as it uses large overscan borders on all sides. True 1080p display can only be achieved by setting the trimmed area to the maximum position (though low quality TVs may not be able to handle the full size, which is why this trimming exists).
Even so, much of the text using small font sizes remains very hard to read, even when perfectly rendered with 1080p output mode.
This can be fixed in a new image by using DragonFace to insert a new parameter definition into the "build.prop" file.
"ro.sf.lcd_density=240"
That will cause the system to rescale the rendering of screen objects to the same physical size as with the current 720p image.
That parameter doesn't exist originally, meaning that the original image falls back on a default value of 160 DPI.
If we consider that a good value for 720p, then for 1080p we need to multiply it by 1080/720 = 1.5, and 1.5*160 == 240.
We can also adjust the value differently, if we want more or less objects per screen than we get with the default DPI.
That can be done for either of the two images, but we always need to adapt the pixel density value to the resolution used.
So to get identical visual readability with both images we do need that density value for 1080p to be 1.5 times the value for 720p.
Now as to the Kodi version used, I find it almost completely unusable for my purposes. The SMB wrapping is not helping at all, as every video I try to launch by "Files" browsing to SMB servers in my LAN always end the same way, with "Can't play this video". The only variation is that sometimes the message comes at once, while it's sometimes preceded by a LONG timeout delay with a spinning circle on screen. That's one half of the reason I find this Kodi unusable. The other half is due to the fact that there exists no PlexBMC-supporting skin that is compatible with this Helix version of XBMC/Kodi. PlexBMC itself does work, but having to go through the Addons menu for each video access is unacceptable, so without a compatible skin there is no point to it.
As I see it the failure of XBMC/Kodi to pass a working SMB path to 'MX Player' (with or without the extra wrapper) is a definite bug in the XBMC/Kodi program code, probably still using some PC related method for handling the passed parameter strings, in some way incompatible to Android. I say this mainly because other programs without any PC relationship have no problems passing SMB paths to 'MX Player'. 'ES File Explorer' is one of the programs I've used for launching videos from SMB servers with playback passed to 'MX Player'. And that works fine every time.
I do not expect XBMC/Kodi to have this bug fixed in any reasonable time, as they are clearly focusing only on their own internal player.
As for the incompatibility of this Helix version to nearly all skins, including all PlexBMC-supporting ones, that may be a temporary problem, but right now it's a showstopper...
I'm going to install an older version instead, possibly an older Helix (the earliest were Gotham-compatible), but probably a stable Gotham version.
Best regards: dlanor |
|
[Copy link]
Post time Nov 13, 2014 02:09
Post time Nov 13, 2014 13:21
Author