this will not be possible because of the hardware the player uses. HP is not standard yet and also doesn't really make sense since it needs a proper hardware to playback. If you have everything in HP you basically will render older computers/media players useless. In times of fast network connections there is also not really a point in saving a few megabytes by encoding like this.
Anyhow you will need some next-gen media player that can handle those files.



No news about this and there is, at this point, nothing planned to change this.



Confirmed happening. We will try to get this fixed obviously in the upcoming firmware.



Will report this to our devs to check what can be done. Thanks for the input!



It's basically loading all modules and mounting the system. We always try to improve but at some point it is technically just not possible to speed things up.



Have you updated to the latest jukebox already? See this post: YAMJ 2.51

What is the bottleneck of the boottime (30 seconds)? The chip? Sad to hear that this cannot be improved.

Thanks for the reply Arne.
I have then followed the instructions and upgraded to 2.5.1, created a new index from scratch.. (took a while, hehe).

On loading the Index.html on the ACRyan, it completely blocked, and had to unplug power.
It has read the index, as on reboot opening it then the index is there.

Maybe it blocked because of the more than 1000 movies in there?
Any chance that this can be fixed, or is there no way to make it read the full index?

Ivo

My experience with v9.5.5.r6629:
1. like reported by many others: the horizontal lines when showing thumbnails
2. DTS HD Master even more difficult to select. In the previous firmware entering the menu (sound) or pause/play (multiple times) was sufficient to get the sound working again. With current beta firmware none of these options work. Can't get it working, and then all of sudden, sound!! Can't reproduce
3. Subtitles sometimes lost when movie was paused.
Anyone the same experience?

All in all I am not quite happy with the release.

Will raise this to our devs to update. Thanks for that feedback!


1. trying to fix in next update
2. reported but not sure if it can be fixed quickly in the next update as this also seems to strongly depend on the type of av receiver (known problems with harman kardon / denon receivers)
3. didn't experience this but will try to recheck - thanks for feedback!

br,

Hi,

I sent this to the support a few days ago. Can anyone reproduce the behaviour?

A MKV video produced by Handbrake 0.9.5 is playing too fast. It behaves like fast forwarding 2x or 4x.
This only happens for the first time a MKV is played. After stopping and playing again the same MKV, the video is fine. All other Handbrake 0.9.5 MKVs are playing fine afterwards.
This is reproducable for the first MKV after the player was started.
I think the problem is the variable frame rate introduced with handbrake 0.9.5.
MKVs of older handbrake version play fine.

1. Player model: ACR-73800 Playon!HD Mini2
2. Firmware version: v9.5.5.r6629
3. Reproducibility: always
4. Setup: Wireless, NFS connection to an Debian server

Here is the mediainfo output for a file:
General
Unique ID : 113671069079061369055917646548594775525 (0x5584406737E781B566083A4F9E76D5E5)
Complete name : C:\records\test.mkv
Format : Matroska
Format version : Version 2
File size : 60.1 MiB
Duration : 10mn 48s
Overall bit rate mode : Variable
Overall bit rate : 777 Kbps
Writing application : HandBrake 0.9.5
Writing library : libmkv 0.6.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 10mn 48s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 112
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=2 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

Audio
ID : 2
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 10mn 48s
Bit rate mode : Variable
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Default : Yes
Forced : No

arno82: It does the same thing for me. The player also plays these videos correctly if you want to continue watching one and select OK in the pop-up window - even if the video is the first one you play after the startup. Additionally I noticed that fast-forwarding is okay, but fast reverse does not seem to work smoothly with such videos.

So you mean that MKVs produced by Handbrake 0.9.5 with h264 Codec play fine for you?
This is interesting, could you please provide a Mediainfo output for a MKV you tried?

They play fine for me...

I would suggest that you upgrade to the latest nightly build of Handbrake which I think is svn4413.

arno82: No. You asked if anyone can reproduce this behavior, and I replied that I have the same problem with the MKVs created by HandBrake using the h.264 format. I misread what you wrote because after the second read I noticed I wrote the same thing as you did: stopping and then restarting the same MKV (that is continue watching a movie) fixes this issue.

I, however, remux every HandBrake-produced MKVs with MKVMerge because that's the only tool I trust when it comes to compliance with standards, but apparently it makes no difference in this case.