1080i vs 1080p

On Mon, 24 Jun 2019 12:30:20 +0100, Mark Carver
wrote:

On 24/06/2019 12:20, Andy Burns wrote:
Mark Carver wrote:

When the Beeb started doing it, some TV receivers didn't change modes
seamlessly, and they (the manufacturers) had to provide patches

My samsung stores picture settings (brightness/contrast/saturation etc)
individually for interlaced and progressive picture types, which led to
to horrid picture flashes when the picture type changed every few
seconds mid-stream ...

Yes, and even after Sony fixed the audio glitch problem on the 2010/2011
models, the firmware still forces you to have to set the overscan on/off
separately in p and i mode (and you can only make the relevant setting
when it's actually in the relevant mode)

I recall that you (Mark) assisted me with this problem at the time.

On Tue, 02 Jul 2019 17:07:58 +0000, Johnny B Good wrote:

On Mon, 24 Jun 2019 03:06:46 +0000, Johnny B Good wrote:

On Sun, 23 Jun 2019 12:24:35 +0100, Indy Jess John wrote:

On 22/06/2019 23:44, Johnny B Good wrote:

However, over the past 6 to 9 months, the iPlayer servers have been
progressively throttling the download speeds from the 50 to 60Mbps it
had previously been until, for the past month or so, it's now at a
paltry 5 to 7 Mbps

Apropos of which, is anyone else using get_iplayer experiencing a
similar speed throttling?

I wonder if this is a time of day thing? I am currently downloading
a
film that was on BBC last night and get_iplayer averaged 25Mbps down a
VM 50Mbps broadband cable.


Lucky you! I rarely see iplayer downloads go faster than 6Mbps these
days (or nights - ToD makes no difference). This evening I saw speeds
in the 5.23 to 5.44 Mbps range. It doesn't matter how many concurrent
downloads are involved, they all run within about +/-5% of each other
whether it's just two or as many as nine or ten on the go.


====snip my fanciful speculations====


Mystery Solved!

It turns out the culprit proved to be my Netgear GS608 v2 8 port Gbit
ethernet switch becoming flakey (most likely down to 'blown' caps but
I've yet to find a 'tear down' video to show me how to break into the
box).


====snip====

After a fruitless search of Netgear GS608 related youtube videos, I
finally tracked down a repair blog describing how to replace the blown
caps. Getting into the box proved ridiculously easy, just 4 torx screws
underneath the pull out push fit rubber feet which even included
retaining flexible anchors to prevent their loss (no glue involved!).

As it happened, unlike the picture showing bulging caps, not one of the
four suspects showed any such evidence of failure. Just out of interest
as to whether the replacements needed to have such high voltage ratings
(10v for the two 1000μF prime suspects, 16v for the 100μF secondary
suspect - the input 470μF needed to be 25v to allow the use of the
original unregulated 12v wallwart with impunity), I discovered that the
voltages were only 2.65, 1.05 and 1.88 volts.

Even 4v rated caps would have sufficed in this case. I was hoping to
find suitably sized 6.3v replacements in my MoBo salvage but they were
too tall so I had to make do with two 10v 1000μF caps and one 16v 100μF
cap. The 1000μF caps were slightly taller than the originals (as was the
470μF 25v replacement - I'd decided to change that one even though it had
had a much easier life due to my replacing the grotty transformer wallwart
with a 12v 1A smpsu wallwart several years earlier). I'd checked them for
fit and reckoned I still had a good millimetre to spare so in they
went! :-)

I don't know why I didn't use my 'scope to check the level of ripple
whilst I was testing the voltages (force of habit from managing without
for so long I guess). Checking the voltages after recapping showed a drop
to 2.55 and 0.99 volts which suggests there had been some hefty amount of
ripple involved to upset the voltage feedback in the switching buck
converter circuitry as to cause such a rise. The voltage across the 100μF
cap had remained at 1.88v implying that the original cap was still in
good condition.

If left to operate in this state for long enough, the switching spikes
will eventually fry whatever is hung off those supply rails. Hopefully,
the weird symptoms had alerted me in time to preclude any such
irreversible damage. I've swapped back from the 5 port switch and the 8
port switch now seems to be operating normally. If there is an incipient
fault as a result of those dried out caps waiting to cause further
trouble, I do still have that 5 port switch as a spare for testing or
replacement.

Of course, with using caps recovered from scrapped PC MoBos, there's the
unanswerable question as to how much life is left before I have to recap
again. I might see a few years more use before it starts acting up again
but at least I now know which two caps to replace and opening the box is
no longer a mystery - it's as if it had been designed with facilitating a
rapid recapping job in mind. :-)

--
Johnny B Good

On 02/07/2019 18:21, Scott wrote:

Yes, and even after Sony fixed the audio glitch problem on the 2010/2011
models, the firmware still forces you to have to set the overscan on/off
separately in p and i mode (and you can only make the relevant setting
when it's actually in the relevant mode)

I recall that you (Mark) assisted me with this problem at the time.

I think I did !

--
Mark
Please replace invalid and invalid with gmx and net to reply.

On 22/06/2019 23:44, Johnny B Good wrote:
For the past few months I've resorted to running get_iplayer in
concurrent Konsole sessions at the end of each evening. In some cases,
I've had as many as 9 downloads on the go, each running at the throttled
speed of 5 to 6 Mbps I get regardless of how many are running
concurrently, indicating that it's nothing to do with the speed of my VM
supplied service unless VM have illegally imposed some weird traffic
shaping policy in order to sell me their own media services. Apropos of
which, is anyone else using get_iplayer experiencing a similar speed
throttling?

Well the service is meant for streaming and they don't really want
people downloading the un-DRMed video so I say be thankful it still
works at all.

--

Brian Gregory (in England).

In article , Brian
Gregory
wrote:
On 22/06/2019 23:44, Johnny B Good wrote:
For the past few months I've resorted to running get_iplayer in
concurrent Konsole sessions at the end of each evening. In some cases,
I've had as many as 9 downloads on the go, each running at the
throttled speed of 5 to 6 Mbps I get regardless of how many are
running concurrently, indicating that it's nothing to do with the
speed of my VM supplied service unless VM have illegally imposed some
weird traffic shaping policy in order to sell me their own media
services. Apropos of which, is anyone else using get_iplayer
experiencing a similar speed throttling?

Well the service is meant for streaming and they don't really want
people downloading the un-DRMed video so I say be thankful it still
works at all.

Here gip tends to run at about 60Mbps before 9am for video fetches, but
much slower during the day, and even slower in the evenings. I assume this
is a contention/capacity issue, not targetted 'throttling/shaping'.

*Radio* gip fetches are often much slower, regardless of time of day. Seems
more an issue of if material is 'new' or 'stale' and I guess after a while
the programes fall out of the cacheing and need extra effort by the systems
to recover and supply.

Do you get the same results in the early morning well before 9am?

BTW in case people don't know: The BBC video 'best quality' had its max
audio rate drop cut 320k to 128k about a month ago. Just in time for the
Proms. :-/

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics https://www.st-andrews.ac.uk/~www_pa...o/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html