tvOS testing 3.0.1 (170223.1644)

[amet]

Please use this ONLY if you have downloaded 3.0.1 (170223.1644) , version number can be seen in TestFlight app

please avoid posting "I would love to test" posts, lets keep this for testing only.

changes since 3.0.0
- fixed, enable YADIF, YADIF_half for arm/arm64
- fixed, h264/interlaced under MediaCodec
- fixed, certain eac3/640kps fail under darwin/audiotoolbox. vector all 640kps to ffmpeg until fixed
- fixed, skin.amber: fix lost focus on home screen
- fixed, remove legacy read size clamps from libdsm/libsmbclient
- fixed, mpeg2/interlaced under ffmpeg
- added, unifont to all skin Font.xml
- changed, read bandwidth limiter and increase our transfer buffer sizes.
- backport, various upstream/sidestream fixes and changes
- version bump, libnfs to 1.11.0

170302.2020
- changed, enable file caching for bluray m2ts files
- fixed, crarfile is sensitive to blocksize
- fixed, add locks in CSocketListener
- fixed, dvddemuxerffmpeg buffer size calc
- fixed, leanback icon
- fixed, droid WOA

[cosmoxl]

The email notice says to test "net buffering". Is that regarding the libnfs update?

[davilla]

The email notice says to test "net buffering". Is that regarding the libnfs update?

All source types. We increased the read bandwidth and disabled the limiter.

[Everbrave]

The email notice says to test "net buffering". Is that regarding the libnfs update?

All source types. We increased the read bandwidth and disabled the limiter.

TestFlight says I need another invitation for 3.0.1


Sent from my iPad using Tapatalk

[cosmoxl]

yadif is in tvOS?
what is fixed for mpeg2 deinterlacing with ffmpeg?

So far good with the new libnfs. Where I previously could not browse my network drive I now can.

since we're on the topic of buffers I do notice there are some content types that seem to never buffer. the "c" line says "forward: 0B 100%"

live tv and recorded tv (via dvblogic), blu-ray folders (via NFS) are the types I've noticed. aq and vq fill just fine (sometimes a buffer period is needed for blu-ray folders). is this to be expected?

[davilla]

yadif is in tvOS?
what is fixed for mpeg2 deinterlacing with ffmpeg?

So far good with the new libnfs. Where I previously could not browse my network drive I now can.

since we're on the topic of buffers I do notice there are some content types that seem to never buffer. the "c" line says "forward: 0B 100%"

live tv and recorded tv (via dvblogic), blu-ray folders (via NFS) are the types I've noticed. aq and vq fill just fine (sometimes a buffer period is needed for blu-ray folders). is this to be expected?

yes, yadif but not enough ponies for 1080i. SD content will be fine for it.
mpeg2, same thing as with fireOS/shield
libnfs, yep. same here.
live and maybe pvr are never buffered. you cannot buffer a live stream
for buffer testing, watch how fast aq/vq fills, or if using buffer cache (200MB is fine), watch how fast that fills.

Over NFS, I'm seeing 30-40MB/s, SMB - 15-20MB/s. Plex usage is also faster to fill but will depend on source (local or way off on the net).
EDIT: of course this is over 802.11ac.

[cosmoxl]

yadif is in tvOS?
what is fixed for mpeg2 deinterlacing with ffmpeg?

So far good with the new libnfs. Where I previously could not browse my network drive I now can.

since we're on the topic of buffers I do notice there are some content types that seem to never buffer. the "c" line says "forward: 0B 100%"

live tv and recorded tv (via dvblogic), blu-ray folders (via NFS) are the types I've noticed. aq and vq fill just fine (sometimes a buffer period is needed for blu-ray folders). is this to be expected?

yes, yadif but not enough ponies for 1080i. SD content will be fine for it.
mpeg2, same thing as with fireOS/shield
libnfs, yep. same here.
live and maybe pvr are never buffered. you cannot buffer a live stream
for buffer testing, watch how fast aq/vq fills, or if using buffer cache (200MB is fine), watch how fast that fills.

Over NFS, I'm seeing 30-40MB/s, SMB - 15-20MB/s. Plex usage is also faster to fill but will depend on source (local or way off on the net).
EDIT: of course this is over 802.11ac.

OK, I'll give you the live tv. I recall when a testflight was buffering live and it took like 8-10 seconds to fill.

I do have my buffer set for all filesystems 20MB. The point is that for those file types I mentioned (recorded tv, blu-ray folders) it seems as though it's not filling that buffer.

Playback of blu-ray folders does cause a few second pause for buffering if aq or vq drop to 0. Usually that happens if I skip forward or backward. Maybe the problem isn't a lack of buffering but a hiccup in the way it's reported to the codec info screen?

Playback of blu-ray folders starts right away with aq and vq fairly low (0 to 20%) and slowly fill up over several minutes of playback. The buffer (or cache as you call it) usage is coincidentally used more and more even though it continues to report it's 0 Bytes.

[davilla]

you might check the setting that controls what is buffered. Internet Streams != SMB, NFS

[cosmoxl]

you might check the setting that controls what is buffered. Internet Streams != SMB, NFS

as I said above, I have it set to buffer all filesystems, not just internet streams.

[davilla]

you might check the setting that controls what is buffered. Internet Streams != SMB, NFS

as I said above, I have it set to buffer all filesystems, not just internet streams.

Make me a video with 'o' on. start playback, let it play for 20-30 seconds, then do a big seek. That will flush everything for refill.

curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"Input.ShowCodec","id":1}' http://192.168.2.44:8080/jsonrpc

^^ will turn on 'o', replace the IP with yours and make sure webserver is enabled.