Messages

That IP is not in a manually maintained blacklist, so there's nothing I can do to unban.

However, I think you have bigger problems than forum posting. Take a look at the reason for the blacklisting at Spamhaus:

Results of Lookup

43.245.171.49 is listed

This IP address was detected and listed 11 times in the past 28 days, and 2 times in the past 24 hours. The most recent detection was at Mon Nov 16 00:45:00 2020 UTC +/- 5 minutes

This IP is infected (or NATting for a computer that is infected) with an infection that is emitting spam.

Note: 43.245.171.49 appeared to be suspicious because it was using the following name to identify itself during email connections (port 25) via the HELO/EHLO smtp commands: ".".

Follow this link to get some more information: https://www.spamhaus.org/css/removal/record/43.245.171.49

We do not know of anyone who still has the issue. If you do maybe you could illuminate us as to who so we can follow up?

I only just found out that the user maindee reported issues on Sunday morning. This was in a post on the Beyonwiz forums https://www.beyonwiz.com.au/forum/viewtopic.php?p=190805#p190805 . There was no concrete evidence to link the issue to the IceTV plugin, but the reported symptoms match those reported previously.

I'm not sure if the above helps you to examine the back end and see if there is anything unusual there. The user "fixed" the problem by turning the machine off and on again, so there isn't much evidence available. This would have been sometime between 8:30am and 10:00am, 1 November 2020.

We do not know of anyone who still has the issue. If you do maybe you could illuminate us as to who so we can follow up?

IanL-S reported instability yesterday and was looking to configure his systems to regularly reboot as a workaround for issues.

One of the problems here is that there is no obvious correlation between the symptoms that users experience and IceTV. The vast majority of users will not look at logs or suspect the IceTV plugin. The symptoms vary. Because the machine runs out of resources, failures can occur in any part of the code, resulting in unpredictable problems. Often these problems do not generate any logs. This lead a number of users to suspect hardware issues.

We did not shrug our shoulders and ignore it

I was not suggesting you did. I mean that I don't want to dismiss this as a non-issue for the Beyonwiz plugin code. I'd like to find the root cause and make the Beyonwiz plugin code more resilient. However, that is not possible without any clues as to what may have gone wrong. Some samples of the data that caused the issues would probably go a long way towards narrowing down the problem. Even server log information may provide some clues - were the responses larger than usual?

There are still some IceTV users that report problems with their Beyonwiz machines.

Has anyone at IceTV figured out what went wrong? What was the nature of the data being sent that caused the denial of service condition on the Beyonwiz machines? I'd like to put in a proper fix so that this does not keep on re-occurring.

I don't like the idea of shrugging the shoulders and saying it was fixed by turning it off and on again. It would be good to know if this is an inherent protocol/API issue, data validation issue, algorithm selection issue or just a plain old bug that needs specific conditions to trigger.

Just don't have an autotimer and icetv trying to record  the same show as mentioned.

Actually, that configuration is perfectly OK. IceTV timers and AutoTimers will not interfere with each other. You can have both and as you have seen, autotimers can do things that IceTV can not.

Is the old management still involved? Are we looking at a phoenix here? A case where the company has gone down in flames, thus shedding any debts and obligations and then from the ashes rises the same company, doing the same business?

What is the story here?

You don't need to reverse engineer the protocol. There is already an open source implementation of the new API on the Beyonwiz T-series. It was available well before the Skippa even went on sale (actually, even before IceTV decided on who would OEM the Skippa) and it was the first PVR to support the new IceTV API.

All you need to do is write a compatible server. I would not bother.

I'll need to learn to use AutoTimers on the T series. My initial research indicates increased blood pressure and Panadol consumption is in my future.

Only if you are hell-bent on never recording a repeat. If you are happy to delete the repeats as you go, you'll be fine. With a 6TB option, you have plenty of time up your sleeve to get around to deleting unwanted shows.

IMHO it's a lot easier to get autotimers to record a few more things and just delete a few shows that you don't care about.

long time away from the forums
...
manage timer clashes

Yes, you have been MIA for a long time.

My advice would be to ditch the DP-Series and get yourself a T4 as the main PVR and a T2 as your development/hacking box. You can trade in your old PVRs when you buy the T-series. Even an old Toppy 5000PVRt will fetch you a $50 credit with Beyonwiz. The T-series are very clever when it comes to timer management and timer conflicts are extremely rare. The T4 will easily record 10 streams at the same time and timers can overlap any way you like.

It's all open source and very easy to hack. Basically, the T-series is the PVR you (and I) really wanted back in the Toppy 5k days ;-)

https://imia.edu.au/HeinzHerrmann

:o

That picture is way, way out of date. It barely bears the resemblance to Heinz you'd meet today.

The rules for employee entitlement protection have been improved in the last couple of decades, so the risk to employees (besides being suddenly unemployed) are minimal. It is extremely unlikely that employees will run any loses. The same can not be said for contractors, although in my experience, if the exposure is large enough and you get yourself a decent lawyer, you can recover as much as 25-33%. Unsecured creditors are looking at 0-3% return if they are lucky.

As far as the "back of the envelope calculations" are concerned, I'm pretty sure that they are way, way off the mark. Probably at least an order of magnitude inflated, if not two.

Another thing to consider is the assets and intellectual property vested in IceTV. Given the multi-tier structure that has been already exposed, I'd be very, very surprised if the entity known as IceTV Pty. Ltd. (the organisation under administration) owned much. I suspect that any intellectual property would be owned by a different entity and IceTV would be licensed to use that technology. The patents applications that come up against ICeTV are mostly lapsed/ceased. The only patents that have been granted/certified (AU2014101162, AU2013101518) are based on technologies that have been commonly used before the application was made and would be trivially challenged in court. (One really has to wonder about the cluelessness of the institutions issuing patents!) This effectively puts any intellectual property either at an arms distance from IceTV or makes it worthless, thus minimising any positive value in the equation when it comes to winding up the business. We already know that IceTV uses the Amazon cloud hosting infrastructure to provision the services, so there would be minimal hardware assets (not that used computer hardware is worth anything anyway) to dispose of. Or in another words - what is there to buy? As far as I can see, IceTV Pty. Ltd. is a bag of liabilities with no obvious assets to acquire.

If the administrator has another view of the value proposition of IceTV, I'd like to see it, but from where I sit, I see nothing worth investing in. Maintaining the guide will at a minimum involve the capacity to employ at least 4-5 people full time, which will require at least $500,000 per year, perhaps more.

I don't see how the EPG could be viable proposition. All the existing customers are a liability, not an asset, because they expect to receive service (in some cases for many more years) without generating any additional revenue for the company.

Time to wake up and smell the manure under the withered roses.

I wouldn't recommend registering as an unsecured creditor. You just end up getting bombarded with meeting minutes and reports all written in 'accountant'. It just makes for depressing reading when you realise how bad the situation is, how much money the insolvency firm is making (at your expense) and how unlikely it is you'll ever see any money.

I made that mistake a couple of times when clients went belly up. Now I just write off the debt and move on.

Just a word of advice on that. If you ever get audited by the ATO, that's not good enough. If you haven't taken reasonable steps to recover those debts, you can't just write them off. What the ATO likes to see is the final wind up letter from the administrator.

As unpleasant (and possibly time consuming) as it is to be shafted out of money, you have to put up with the administrators rubbing the salt in it too. :-(

I know, I've been through this several times too, to the tune of hundreds of thousands of dollars.  >:(

Given the volatility of the current situation, I would very much recommend that you make all updates available as beta releases as soon as you receive them. Let interested people download the firmware image and apply it via USB. Also provide the latest official release as a USB update so that they can roll back, if it's worse than what they had before. By all means, follow the normal testing process for a general release, but also make sure that the update gets to someone ASAP. There are two very good reasons for that:

1. You will get help testing the fix from many people, so your QA will go faster. (And those people are willing to help and understand the risks of using a beta.)

2. If the release turns out to be good, but the administrators lock you out of the building tomorrow morning, then your customers will not miss out on an update that could have eased their pain. It'll be out there.

it looks like the Beyonwiz t4 is the only "real" choice for a PVR with 3 or more tuners.

Actually, the Beyonwiz T2 is a much cheaper choice and it ships with an extra USB tuner, which makes it a 3 tuner PVR.

You could actually convert your Skippa boat anchor into $50 credit towards a new Beyonwiz T2, given their current trade-in offer!

This statement in the manual refers specifically to the IceTV login and related subscription detection on SKIPPA (account and AutoSkip), and prohibits hacking / decompiling of the firmware in any way - particularly in terms of this subscription detection mentioned above.

First of all, the term "conditional access" has a very specific meaning in the STB/PVR industry, so the choice of that terminology is a bit unfortunate. You may wish to revise it.

However, moving onto a more important matter, I think you may have a few issues here...

As far as I can tell from all the info on the forums, the box is based on a Broadcom STB reference design. That means it's running a Linux kernel, which is licensed under the GPL. It's impractical (actually close to impossible) to build a modern Broadcom STB/PVR (especially one that can run Opera), without GPL, LGPL and other Open Source components. That means that not only is it perfectly OK for anyone to take apart the firmware and see how it works, but it also means that you have to provide the source code to the GPL and LGPL components, including any modifications you have made. On top of that, the LGPL also requires you to ship the code in such a way that anyone can replace the LGPL components with whatever alternative version they choose and still be able to rebuild a fully working firmware. That means that your code must be supplied in a format that is readily usable by anyone wishing to modify the firmware. Most commonly this is done by shipping proprietary code as a set of shared libraries with corresponding header files that provide a public API.

Of course, your intellectual property is still protected by your copyrights, but you can not restrict the rights that the end users have as a result of you choosing to use GPL, LGPL or other Open Source code to build the product.

The GPL and LGPL licenses (and probably other licenses, such as the JPEG library code) also require you to publish the licensing terms in your manuals. Even the most permissive licenses, such as 3-clause BSD License, require you to publish the license terms. You should probably talk to your OEM about third party and Open Source licensing compliance and get them to furnish you with the required licenses and corresponding code.