USB Partitioning - why so much waste?

Hi  -  I was not getting any viewable output from running the Rasplex on the SD card so now run it on a new 16GB Transend Jetflash which is quite a fast drive. There is some improvement with the odd occassion of 'pausing' on H264 1080p files - still very annoying though. Is there any way and is it worth expanding the partitioning on the USB?  Currently it has the following partitions:

System(FAT)250mb(used)

Storage(Ext4)1.2GB

Unallocated 13.3GB

I would have thought that 1.2GB for the storage would be more than enough for a 2.6GB file. I take it that all the caching/buffering is done the the storage section.

 

Also under the preferences/quality I get the best results at under 2 mbps - which is rubbish really.

 

I would appreciate any comments or ideas to improve the output.

many thanks

 

Richard

Hi  -  I was not getting any viewable output from running the Rasplex on the SD card so now run it on a new 16GB Transend Jetflash which is quite a fast drive. There is some improvement with the odd occassion of 'pausing' on H264 1080p files - still very annoying though.


The 1080p designation itself doesn't really say how much a video will 'load' either the network or the CPU/GPU combo. It is the overall bitrate which determines the network load and also has a strong influence on the CPU/GPU load (together with video/audio CODECs).

Extreme bitrate videos will probably always pose a problem for an RPi (regardless of firmware), but most 'normal' 1080p encodes should be possible to play without stutters, though the upper range of such encodes may require some special measures to speed up the RPi, including the use of USB drives which you're already familiar with. The other special measure I spoke of is overclocking the RPi.

My own overclock values are as follows:

arm_freq=950
core_freq=450
sdram_freq=450
over_voltage=4

I've placed those values close to the end of the config.txt file, so that they'll override any other assignments to those variables.

If even this does not suffice for some extreme bitrate videos then you may have to lower your maximum bitrate for transcoding, and if even that fails to eliminate the stutters you may have to consider the possibility that your PMS server is underpowered for such transcoding.
 

Is there any way and is it worth expanding the partitioning on the USB?


I'm not sure how much can be gained by expanding the partition (nothing if that space is never used).

But it certainly can't hurt anything to have additional space available, so I've expanded the size of my Ext4 partition to fill out all the unused space 'behind' it in the partition scheme. I did this by using the freeware edition of the "Paragon Partition Manager", which allowed me to expand the existing Ext4 partition without affecting its contents.
 

Currently it has the following partitions:

System(FAT)250mb(used)
Storage(Ext4)1.2GB
Unallocated 13.3GB

That's not quite correct. The full operating system is not stored on the FAT32 partition, but is stored in various folders on the Ext4 partition. This is necessary as a FAT32 partition doesn't support file attributes required by Linux. The FAT32 partition is only used for the initial bootup, partly because that's how the RPi's built in boot-loader was designed, though it also provides a simple method for non-Linux users to access and modify some basic configuration files (copied to the Ext4 system for each boot session).
 

I would have thought that 1.2GB for the storage would be more than enough for a 2.6GB file.

For most videos it would be, though it depends both on the total video size and the percentage of caching used.
And the available space is also used for other things than playback caching, such as caching of library meta-data.
 

I take it that all the caching/buffering is done the the storage section.

Yes, the FAT32 partition is never used for such purposes, and the unallocated space is of course unusable until you expand the Ext4 partition to use it.
 

Best regards: dlanor

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.