Streaming to TV

raydon said:
Sorry but I don't follow your reasoning here. Why should this affect a shrink operation ?. The original goes into sub folder "_original", the shrunk file stays where it is.'
Click to expand...
It doesn't directly but if one of the filenames isn't changed, the owner can't subsequently put both old and new in the same folder.
This affects one of the common workflows for cropping multiple segments from a recording but the same filename generation was added for all modifications at the time.

I don't remember why SDT frames aren't stripped. The original motivation was to save recording space and the effort went into removing EIT and confirming that playback wasn't affected (so long as the .nts was properly updated along the way).
 
af123 said:
It doesn't directly but if one of the filenames isn't changed, the owner can't subsequently put both old and new in the same folder.
This affects one of the common workflows for cropping multiple segments from a recording but the same filename generation was added for all modifications at the time.
Click to expand...
So are you saying this is not really necessary for a shrink operation ?
 
Yes, it is not really necessary for shrink apart from to avoid any surprises caused by having two identically named files in the system. The only surprise I can envisage is the inability to move the original back while the new file is in place (or maybe it will overwrite, I haven't tried).
 
af123 said:
Yes, it is not really necessary for shrink apart from to avoid any surprises caused by having two identically named files in the system. The only surprise I can envisage is the inability to move the original back while the new file is in place (or maybe it will overwrite, I haven't tried).
Click to expand...
In that case I agree with trev and prpr.
I will be leaving my edits in place as I don't see the point of having to wait for a reindex of the DLNA database . Better I think to rename the non-critical backup which is destined to be deleted. Would be nice if I didn't have to reinstate edits after every webif update but it's up to you. :)
 
Last edited:
Interesting discussion - am enjoying the forum.

I think i'm going to have to give up trying to get it to play on my Panasonic TV. I was also going to put the Hummy in one room and have it connect to the TV upstairs, but thats not going to work now, which is a shame.

Thanks all
 
There's more than one way to skin this particular cat. Alternatives currently in use by members of this forum include:
  • Using a decent quality analogue cable and putting up with lower res pictures;
  • Using good quality HDMI leads in excess of 10 metres;
  • Using an HDMI active switch or extender amplifier to double the reach;
  • Using HDMI to Cat5 conversion (dedicated point-to-point Cat5 cable, longer reach than HDMI);
  • Using HDMI to network conversion (launching HDMI into the home network for recovery by a dedicated receiver);
  • Using another HDR-FOX or HD-FOX as a DLNA media client (home network);
  • Using another HDR-FOX or HD-FOX as a networked extension to the master HDR-FOX (custom firmware);
  • Using a third party media player for DLNA access or network file share (eg Raspberry Pi);
  • Installing MediaTomb as an alternative DLNA server (custom firmware, decryption of source material required) with the possibility that the TV client gets on with it better.
(List extended in the light of subsequent discussion)

In cases where there is no line-of-sight for the remote control handset and no return channel for RC commands, a wireless AV video extender can be used to provide the return channel, or the custom firmware provides a virtual remote that works via the network.

This topic might give you some ideas: http://hummy.tv/forum/threads/problems-using-hdmi-over-cat5-extender.6387/

NB:

Extending the video output from the HDMI or analogue video connectors obviously requires no special measures other than being able to command the Humax.

Accessing recordings by DLNA (over the home network) requires no special measures for StDef recordings (other than a compatible client), but HiDef recordings are locked and will only stream to another Humax or device able to negotiate protected delivery (no non-Humax clients capable of this have been identified). This restriction can be removed using custom firmware, but the client would still need to be compatible with the HiDef .TS file and have enough processing power to cope with it. Using MediaTomb as an alternative to the native Humax DLNA server requires all source content to be decrypted before it can be streamed.

Accessing recordings by file share requires custom firmware to provide the remote access, and that the recordings are decrypted (custom firmware takes care of this). This method means a client does not have to be DLNA compatible; as long as it can read the files, it will proceed as if the source file is stored locally. This is particularly useful if the client is another HD/HDR-FOX because the full range of playback and recording management options become available.

Note that Foxsat-HDR can do similar things (as a server), but requires different configuration. HDR-1800/2000T is restricted to DLNA access due to there being no custom firmware for it, and manipulation is required to achieve HiDef streaming.
 
Last edited:
I have updated my previous post while you were posting yours. There are now also significant updates to post 26.
 
Last edited:
The advantage of using an open source platform such as RPi rather than a branded media playing HDMI stick is that you are pretty much guaranteed codec updates etc will be available indefinitely. Getting your hands "dirty" and figuring out what and how to install the necessary support software puts it under your control, and you will be less likely to need someone else to sort it out if and when something goes wrong.

Having said that, I had a quick play with one of the standard packages for RPi and it just installed and worked out of the box.
 
When did I ever claim my word should be taken as gospel? In any case, to be pedantic, I can't see any logic in MediaTomb altering the ability of the client to decode and display a TS file. If it somehow makes the client work with the Humax, the client must already have the capability for TS files and it has to be something to do with the Humax server not presenting the metadata properly.

This is something I have not considered before. It will be interesting to see what happens.
 
I have installed MediaTomb on one of my machines to have a play. A couple of comments:
  1. It would be nice if the MediaTomb icon on the WebIF front page occupied the same space as the other icons;
  2. It would be nice if it was not necessary to go chasing into Telnet etc to change the server name it presents on the network.
 
You must log in or register to reply here.
Back
Top