Would it be possible to somehow use a folder with JPG photos >8.3 megapixels to generate a videostream on the fly on a Debian based NAS that is played back on the Vero4K? For example via DLNA/UPNP? Instead of creating a slideshow video first.
I have not yet found software that can do this…
ok guys, it is 2020. Don’t you think it would be nice to be able to watch our picture in 4k native on our 4k (or above) device with the Vero4K?
Any news on that side?
Vincent
As mentioned above, you can do this, but you can expect a significant performance hit in doing so.
It’s something we’ll look in to in the future, but it is low priority at this time. Kodi v19 still has not been released.
Hi devinv, I totally agree, that this is a very important feature for me too. But currently it is not avaliable so my question is, if you found a solution outside the vero / kodi enviroment.
I don’t know what you mean by outside of the vero/kodi !?
I can obviously see my picture in 4k using my tv and its crappy picture viewer or my main computer.
I wish I could use my vero 4K for that
My hope was, that you found in the meantime another Software or Hardware that works.
using the Vero4K? nope, unfortunatly.
We will look in to it again after 4.9
Hi Sam,
I connected to 4K screen, and then I manually changed the resolution using fbset in /etc/rc.local
This is what it was (and it was working ok)
sudo fbset -g 1920 1080 1920 1080 32
This is what I changed it to…
sudo fbset -g 3840 2160 3840 2160 32
Unfortunately, Vero4K+ now hangs at boot. And I can’t ssh 
Very strange ssh, becuase I can connect and authenticate - but it can’t start a terminal session.
Here’s the output from ssh with -vvvv option
NiallOfficeMBP-11963:~ Niall$ ssh -vvv pi@192.168.1.103
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.103 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.1.103 [192.168.1.103] port 22.
debug1: Connection established.
debug1: identity file /Users/Niall/.ssh/id_rsa type -1
debug1: identity file /Users/Niall/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Niall/.ssh/id_dsa type -1
debug1: identity file /Users/Niall/.ssh/id_dsa-cert type -1
debug1: identity file /Users/Niall/.ssh/id_ecdsa type -1
debug1: identity file /Users/Niall/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/Niall/.ssh/id_ed25519 type -1
debug1: identity file /Users/Niall/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/Niall/.ssh/id_xmss type -1
debug1: identity file /Users/Niall/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u4
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.103:22 as 'pi'
debug3: hostkeys_foreach: reading file "/Users/Niall/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/Niall/.ssh/known_hosts:36
debug3: load_hostkeys: loaded 1 keys from 192.168.1.103
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
debug2: MACs ctos: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
debug2: MACs stoc: hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:u3qCMfyFSN7LA7tdtK1Lz+ApsfQInVUd7ZTjXli/OwQ
debug3: hostkeys_foreach: reading file "/Users/Niall/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /Users/Niall/.ssh/known_hosts:36
debug3: load_hostkeys: loaded 1 keys from 192.168.1.103
debug1: Host '192.168.1.103' is known and matches the ECDSA host key.
debug1: Found key in /Users/Niall/.ssh/known_hosts:36
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /Users/Niall/.ssh/id_rsa
debug1: Will attempt key: /Users/Niall/.ssh/id_dsa
debug1: Will attempt key: /Users/Niall/.ssh/id_ecdsa
debug1: Will attempt key: /Users/Niall/.ssh/id_ed25519
debug1: Will attempt key: /Users/Niall/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/Niall/.ssh/id_rsa
debug3: no such identity: /Users/Niall/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /Users/Niall/.ssh/id_dsa
debug3: no such identity: /Users/Niall/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/Niall/.ssh/id_ecdsa
debug3: no such identity: /Users/Niall/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/Niall/.ssh/id_ed25519
debug3: no such identity: /Users/Niall/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /Users/Niall/.ssh/id_xmss
debug3: no such identity: /Users/Niall/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
pi@192.168.1.103's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to 192.168.1.103 ([192.168.1.103]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x48
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env TMPDIR
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_IE.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env XPC_FLAGS
debug3: Ignored env XPC_SERVICE_NAME
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env DISPLAY
debug3: Ignored env _
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
Q: Is there anyway I can re-edit /etc/rc.local … like with an SD card or USB or something…
Is it possible to boot Vero4K+ from a USB and connect to WiFi, and then edit a file on the internal partition? Maybe one of those linux distros that runs on USB stick?
Otherwise, I’ll try with USB keyboard. I’m waiting for one which I’ve ordered.
I think I can CTRL-BREAK-F1 or something like that to get to the command prompt.
Thanks!
Try holding SHIFT when you’re booting.
This should give you an emergency console where you can edit it back.
Sam
Thanks Sam.
I added this in /etc/rc.local
echo 2160p60hz > /sys/class/display/mode
I think it’s higher resolution now, but only a quarter of the screen is used
I’ve tried a few fbset settings, like this…
sudo fbset -g 3260 2160 3260 2160 32
But it just hangs.
Any ideas?
thanks.
I think Kodi and the Device Tree would still need to be adjusted for this to work properly.
Even if you start Kodi, the scaling will be wrong.
I tested the interface at 4K, and the performance wasn’t acceptable, at least for this version of device.
Sam
This sets the correct resolution:
echo 2160p60hz > /sys/class/display/mode
But I think the framebuffer size is too small (just using a quarter of the available screen)
Is there anywhere I can find the correct fbset settings so that the framebuffer can use up the full screen?
I’ve tried some of these, but can’t seem to get it …
pi@sam2:/sys/class/graphics/fb0$ more modes
U:2000x1024p-0
U:1280x1024p-0
U:3260x2160p-0
U:1280x720p-0
U:1920x1080p-0
thanks
You would need to patch the Device Tree so enough memory is allocated to provision a 4K framebuffer.
But Kodi patches would also be needed to create a larger GLES surface. When this is done, the GUI performance is choppy.
There may be a better approach to do some resolution switching on the fly when the user opens the Pictures portion of Kodi.
Currently we only provision for 1920*2205 which is larger enough for a Frame Packed 3D image.
Sam
It’s now Sept 23 and having read the above the V version about to launch, Can it play 4K photos at 4k with out down scaling to HD?
I have 8K 48Mpix and 6K and 4 K photos and video from my camera over the last 7 years and they look amazing on a 4K oled but I have never managed to get photos to shine at 1080 upscale. My 10 4K+ Veros can’t do it. I am on a confluence skin altered specially to encrypt the256GB SD card and to play on Kodi 17 as afterwards it seems to have problems.
I work equally making video and photos of nature in cinematic quality so since Vero was the core of my display path, I snooker with 10 boxes that cant do it and I don’t have personal knowledge or skills to apply patches or compile etc. I never thought stills would be so forgotten as a file.
Has anybody made it work in the last 6 years since the post started?
Thanks
and what of the V with photos.
All cameras take both pictures and video. Making stills into video files create massive files of data that cant be stored and totally inefficient. and leaves no space for existing video 4K files that already fill the 256 card and will double soon as I edit more
Great question.
So in theory: this should work with the version of OSMC you receive. This is because we had the 4K framebuffer on by default. But Kodi didn’t any better, because of the scaler.
@WilliamG also reported an issue, so I reverted the change as discussed here: 3840x2160 UI appears interlaced. I’m happy to revisit this in the near future however.
@anbodearg has purchased a device and it should be with him shortly. The software he receives should be old enough that he will have the 4K framebuffer enabled. Maybe he can test his photos and see if they look improved before updating
Sam
Thanks Sam. Appreciate your quick response.
So native ultra HD is the normal UI with V now without compression or expansion paths for ultra HD content images etc?
I didn’t understand the detail re what’s the process of the scaler?“But Kodi didn’t any better, because of the scaler”. Be good to understand the process clearly for handling the still image files.
And to confirm the note re Profile - anbodearg - OSMC Forums
Is current to V situation now not an old post?
Re 4K+
Was there any progress by anyone in that 6 years? I still have 10 boxes to deal with. Someone with IT skills may be able to help me but need to make it as easy as possible for him to implement if he is willing and able to help. Many thanks for any input Mark in New Zealand with thousands of nature images and 20TB of 6K footage.
The OS as shipped had some tweaks that were reverted with updates as they caused artifacts. Kodi as it stands right now has some limits when it comes to displaying the UI (and by extension pictures) at resolutions above 1080p. The Vero V hardware has more capabilities in this regard hardware wise than previous models but there would need to be software changes made to get you to where you want to be. These software changes will be getting looked into in the near future.
You would need to point to the post and not the user profile for someone to answer that.
We will look in to it soon and update this thread.
Sam