Play RAR files without extract them on SMB/NFS (RAR2FS?)

[hasse69]

Ah, yes. Did not expect any improvement. Only more logging for troubleshooting. Will get back with a new patch. Think I see what may be the problem.

[hasse69]

Try this.

[juusso]

First: 4 secs playback. http://pastebin.com/rDWJBhkz
Second: Got playback , but after few seconds (10 or more) got picture frozen. Log is only until freezing came, but after a while of waiting it started to talk in background, but no picture came - just frozen one. Only audio track is ok.

[hasse69]

*sigh*, the log looks better, but there are still issues with the reader thread, it does not get enough CPU! Can you try again, this time without using the -f switch? That is, start rar2fs as a real daemon.
You then need to umount to release the mount point.

[juusso]

Average of movie with picture freezing is CPU about 25% (with -f key). The only at beginning it was about 98%, but later dropped and kept stable at 22-25% level.

Code: Select all

Mem: 163408K used, 134496K free, 0K shrd, 6108K buff, 88768K cached
Load average: 2.85 1.21 0.45  (Status: S=sleeping R=running, W=waiting)
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
   45 root     S N    51652    43 22.3 17.2 exeDSP
   51 root     S        172     1  1.1  0.0 telnetd
  566 root     S N    10572   543  0.7  3.5 rar2fs
  565 root     R        728   562  0.5  0.2 top
  616 root     S N    14072   566  0.3  4.7 rar2fs
  533 root     S       3452     1  0.0  1.1 smbd
  542 root     S       2772   533  0.0  0.9 smbd
  544 root     S N     2012     1  0.0  0.6 httpd
  548 root     S N     1484   544  0.0  0.4 httpd
  547 root     S N     1484   544  0.0  0.4 httpd
  549 root     S N     1484   544  0.0  0.4 httpd
  520 root     S        464     1  0.0  0.1 dropbear
  535 root     S        424     1  0.0  0.1 vsftpd
  562 root     S        380    51  0.0  0.1 sh
   31 root     S        356    25  0.0  0.1 rc.local
   25 root     S        344    24  0.0  0.1 rc.local
  543 root     S        336    51  0.0  0.1 sh
   43 root     S        320    31  0.0  0.1 rc.local
   24 root     S        284    23  0.0  0.0 rcS
    1 root     S        264     0  0.0  0.0 init
   23 root     S        108     1  0.0  0.0 init

Without -f key situation same - playback stopped to play at same place, but audio track seems is ok. Also no cpu overload here. Just at the beginning rar2fs was about 70%, later drops to 21-24%

Code: Select all

Mem: 161520K used, 136384K free, 0K shrd, 6128K buff, 87064K cached
Load average: 3.09 1.38 0.54  (Status: S=sleeping R=running, W=waiting)
  PID USER     STATUS   RSS  PPID %CPU %MEM COMMAND
  569 root     S N    10252     1 73.4  3.4 rar2fs
   45 root     S N    51616    43 23.7 17.2 exeDSP
  572 root     R        728   571  1.4  0.2 top
  487 root     SW<        0    13  1.1  0.0 rpciod/0
  619 root     R N    14072   569  0.0  4.7 rar2fs
  530 root     S       3452     1  0.0  1.1 smbd
  539 root     S       2772   530  0.0  0.9 smbd
  542 root     S N     2012     1  0.0  0.6 httpd
  548 root     S N     1484   542  0.0  0.4 httpd
  547 root     S N     1484   542  0.0  0.4 httpd
  549 root     S N     1484   542  0.0  0.4 httpd
  517 root     S        464     1  0.0  0.1 dropbear
  532 root     S        424     1  0.0  0.1 vsftpd
   31 root     S        356    25  0.0  0.1 rc.local
  565 root     S        348    51  0.0  0.1 sh
   25 root     S        344    24  0.0  0.1 rc.local
  571 root     S        336    51  0.0  0.1 sh
   43 root     S        320    31  0.0  0.1 rc.local
   24 root     S        284    23  0.0  0.0 rcS
    1 root     S        264     0  0.0  0.0 init
   51 root     S        172     1  0.0  0.0 telnetd

[hasse69]

Average of movie with picture freezing is CPU about 25% (with -f key). The only at beginning it was about 98%, but later dropped and kept stable at 22-25% level.

Well, is not that much about CPU usage in general, it is more of CPU offered by the system to the reader thread. It seems it gets a lot of CPU once, but then it is starved out.
But I do not think that is the root cause of the problem to be honest. If you generate a .r2i file for Shrek, what is the output from playback then? Maybe it is time to compare?
The strange access pattern applied by the MediaPlayer is more than odd. Why would it read old data over and over again?

[hasse69]

Try this and see if it makes any difference. I try to fill the index array with 0xff instead of 0 and the reader thread is implicitly turned off.
But I do not have much hope I am afraid

EDIT: I have now checked, double checked and triple checked the logic when jumping backwards in the stream and I can not see any errors on any of my reference platforms. The few bugs that were actually found have been fixed but still does not seem to improve the situation on the Samsung platform
I guess one option now is to run using the --save-eof flag since I am still more or less convinced that the MediaPlayer on this system just will not cope with fake index table data. If you get the chance to test also a compressed .mkv that would be great. That could tell if the problem is isolated to .avi files or if it is a common thing.
If it is pure .avi related, then depending on if the player adhere fully to the AVI specification or not, we could try to reset the AVI_HASINDEX flag in the AVI header to see if it makes any difference.

[hasse69]

Ok, after spending some time on writing a complete comparison engine and generating random access patterns into the I/O stream I actually found a few exotic bugs.
In the patch provided all (so far discovered) bugs should be fixed. Please try it, I hope it will make a difference.

Note that there are two files in the patch that need to be replaced.

[juusso]

Patch15:
Shrek -same 4sec playback. http://pastebin.com/x76XWxZe
av1.0: buffering time was significant shorter and quicker compared to playback of same file before, but movie stopped to play exact at same place. Just only audio is ok.

[hasse69]

The logs look ok, there are no unexpected errors! It seems the player just gives up for Shrek after a while
For the AVI1.0 and no video it is most probably because the player lost frame sync during playback.
The logs are very clear. A common pattern seems to be that after a few or only a single read the player
request a new read from a historic buffer, eg. something it has already read before. I think it is confused
because of the fact that there were no proper index table provided at load time The lost sync could
also be related to the fact that the reader thread is scheduled very sparsely. I do not how much more
effort should be put trying to get this to work. From what I have seen so far it seems more or less
impossible due to the player constraints on this platform

What could be tested next is an .mkv instead. To check if this is unique to .avi or not.
Also, I could try to raise the thread priority a little bit to see if the video sync issues are resolved but it will not help for Shrek!
You could also try to raise the priority of rar2fs by starting it with 'nice --20 ./rar2fs ....'.

You can (as tested before) run with the --save-eof flag. This will most likely help also for AVI1.0.
But then you must make sure the exported file system is writable and at first playback it will take some
time before it start due to the post-processing. But once the file is created that will no longer be the case.