IPTV Users...

[crackt]

the last few days i have actually spent some time trimming my channel list and doing some labelling. i have been using maz becuz it seems to be the only thing remotely working. i wish these programmers shed the egos and placed their knowledge into the communities hands but thats another topic. hah. anyways. i had been grabbing channel backups for every so many edits. tonight i couldnt seem to tune any iptv channels. so i attempted to delete the group and reload the http_streams file. the azbox gave me an error i havent seen before about operation couldnt be completed please reboot. i looked at the last channel grab i took and i had hundreds of copies of the iptv channels in my list. it didnt seem to affect the channel count in any logical way. i deleted all the iptv channels and rebooted my box. to my slight surprise i had the iptv channels still in my list. i then decided to delete the http_streams file. i had been having some flaky performance issues with my azbox lately. i hope this channel glitch was my issue.

it is my hypothesis tho that rebooting the azbox with the http_streams file still on DISK2/ creates duplicate channel list entries that fudge the box up. since it is now my main use reciever i will find out in the next few days if this really is an issue. and if i have time (i have a dish farm overhaul to complete and look for a 7 way cband lnb / feed shootout soon) i will even try to reproduce the behaviour.

crackt out,.

 

[nycrich]

I believe their is a bug in the IPTV part of the software using 9.4980 . I manually added one channel with the remote since Maz3.0 does not load/work for me. It shows, then my regular sat started losing transponders and sats everytime I power up. I did not change anything/scan/added to my sat when the problem occurred.
I reload a new bin and still had the problem. I then whent backwards into the steps before the problem started. I deleted the IPTV channel and reload patch file again. All sats that was greyed out/missing came back. Definetly there is some bug with that part of the software.

 

[donaldelee]

IPTV

The STB [HD Premium Plus] does indeed act flaky with the IPTV. I had to go into Maz, and delete the IPTV. Now, all is great!

Now, I am wondering what it will work like with the latest firmare? ? ?

 

[Babadem]

Firmware Ver.9.4980 is definitely an IPTV killer, and has made my AZBox behave erractically. I will roll back to ealier firmware soon. Meanwhile, I have switched off my AZbox for a day now to give it a rest.

 

[crackt]

so i drank some beers and reverted to 4754 and played with my az. took the buffer size down to 8 and i noticed the following.

sat_action had a few more channels in his list.
lowering the buffer size increased channel load times and actual channel locks.
after 128 we arent gaining anything. i lowered the buffer to 8 and after 128 it only made things worse.
my line is rated to 5mbs but ive only ever sustained 3mbs speeds.

test it out.

crackt out,.

 

[Babadem]

so i drank some beers and reverted to 4754 and played with my az. took the buffer size down to 8 and i noticed the following.

sat_action had a few more channels in his list.
lowering the buffer size increased channel load times and actual channel locks.
after 128 we arent gaining anything. i lowered the buffer to 8 and after 128 it only made things worse.
my line is rated to 5mbs but ive only ever sustained 3mbs speeds.

test it out.

crackt out,.

This is worth a try. Did you try your modified IPTV list using firmware version other than 4754?

 

[crackt]

This is worth a try. Did you try your modified IPTV list using firmware version other than 4754?

i was at 4931 when i started tinkering. i knew the iptv was bogging down my box but i have been testing other gear lately. i reverted file by file to 4754 and i dont think i have gone far enuff back. a buffer size of 8 didnt change much over a buffer size of 128. 128 seems to be the ideal size for my line speed of 3mbs. i just have to find where the iptv issues start in the firmware now.

crackt out,.

 

[B.J.]

I don't use those internet IP TV sites (I did try them once when the capability was first announced, but my internet isn't fast enough, so I haven't tried since). But all this recent talk about the most recent firmware versions messing up IPTV had me reluctant to try upgrading firmware, because I was afraid that it would affect IP streaming over the LAN. Today, however, I messed up my Azbox trying to remember how I created IP channels to computers on my LAN, and accidently wiped out all the sat/channel data. So I figured that since I was starting over from scratch, that I'd give the new firmware a try.
So I put in that recent 0.9.4931 version. Anyway, I'm happy to report that the UDP streaming still works across the LAN in this version. I haven't tried HTTP streaming. Never did have much luck with that with the old firmware.
So for anyone concerned about the new firmware killing regular streaming, it doesn't seem to be a problem. Or at least I haven't run into any problems yet.

But this also makes me wonder if it might be possible to manually enter those IPTV channels manually via the remote instead of via that text file, since the manual entry seems to work for the LAN streaming.

When I accidently deleted all my sats/channels, I was trying to add a new UDP channel, and when that failed, I tried to delete an IP channel, and the thing went beserk. When I reloaded an old sat/channel data set, and once again tried to add an IP channel, it worked, but for a minute, all the regular sats got grayed out, sort of like people were reporting with respect to what happens with the IPTV problems, however on switching sats, they all came back on their own, sort of like the Azbox just needed a little time to set up all the channels. Anyway, I was afraid that it didn't work at first, but it did work, and I can stream from other computers via the UDP IP channel.

 

[crackt]

how responsive is your box bj ? i found that with the newer firmware the box would slowly become very unresponsive after a few minutes. almost as if there is a memory leak somewhere in the newer code. i couldnt even get into the tuner menu with the newer firmware. anyways. from reading the changelogs there really isnt anything im interested in so ill keep back testing code.

crackt out,.

 

[B.J.]

how responsive is your box bj ? i found that with the newer firmware the box would slowly become very unresponsive after a few minutes. almost as if there is a memory leak somewhere in the newer code. i couldnt even get into the tuner menu with the newer firmware. anyways. from reading the changelogs there really isnt anything im interested in so ill keep back testing code.

crackt out,.

I didn't notice any slowing response. Used it all day yesterday. First streaming a few UDP files from VLC on a LAN computer, then going back to playing a sat channel, then later in the evening used the Azbox File Manager to play some video I extracted from a DVD. Everything worked normally. Maybe I'll run into problems when I start adding more sats/transponders, since I had to revert to an older set of sat/channel data yesterday, and I don't have all the sats/transponders/channels set up yet, but it's about 50% set up.

My theory is that strange things like this happen when the sat/channel data get corrupted, and really the only way out is to go back to square one when that happens, and that the use of these text files to create channels might be corrupting the channel data. I had some similar issues with the browser function, since there is a file in the disk2 section that defines all the URLs, but it was kind of tricky getting this file in the proper format, and if anything was wrong with the file, the thing bombed.

 

[Babadem]

i was at 4931 when i started tinkering. i knew the iptv was bogging down my box but i have been testing other gear lately. i reverted file by file to 4754 and i dont think i have gone far enuff back. a buffer size of 8 didnt change much over a buffer size of 128. 128 seems to be the ideal size for my line speed of 3mbs. i just have to find where the iptv issues start in the firmware now.

crackt out,.

I reduced the buffer size to 128 using Ver 4754, but my problems still persist. In the IPTV mode the channels display fine, but when I go to "Settings" menu either from regular Satellite channel or IPTV channel, it gets stuck with a massage like "Please wait........" indefinitely, unless I reboot. As soon as I delete the IPTV channels and Http_streams file, Azbox comes back to normal. Btw, 4931 is not working very well for me. UDP streaming via VLC is not working. I have gone back to 4829.

 

[B.J.]

I reduced the buffer size to 128 using Ver 4754, but my problems still persist. In the IPTV mode the channels display fine, but when I go to "Settings" menu either from regular Satellite channel or IPTV channel, it gets stuck with a massage like "Please wait........" indefinitely, unless I reboot. As soon as I delete the IPTV channels and Http_streams file, Azbox comes back to normal. Btw, 4931 is not working very well for me. UDP streaming via VLC is not working. I have gone back to 4829.

Strange, relative to the UDP streaming not working, because as I mentioned in msg#8 above, I switched to 4931 firmware and UDP streaming from VLC worked fine for me, and I had none of the issues on going back to Settings. It seems like perhaps it's the HTTP channels are what's messing things up. Either that, or problems begin once you try adding more sats or channels, which I haven't done yet. I'd really suspect the HTTP things are at fault, because I detected problems with the HTTP implimentation before. I can't find my post about it right now, but I do remember that to get HTTP channels created manually, ie not by using that text file, that, I had to put an extra digit in for the port number because the Azbox was apparently ignoring the last digit. And if these IP channels created via the text file are working, then perhaps the channel data file is being corrupted by the way the HTTP channels are stored. I also posted about not being able to make any sense out of the info that was being stored in the channel data file for the HTTP channels. Ie for the UDP channels, you could see the IP#s in the channel data retrieved by MAZ or Azbox-Edit, but the data saved for the HTTP channel (seemed that you could only store one manually) seemed like gibberish.

Anyway, it's strange that you couldn't do UDP with 4931, because it worked for me.

 

[drboyddrboyd]

OK, I'm an idiot.

What is UDP streaming?

 

[B.J.]

OK, I'm an idiot.

What is UDP streaming?

Then I'm an idiot too, because I don't understand completely either.
But UDP and HTTP are just 2 formats that are used to transfer data across a network, ie user datagram protocol and hypertext transfer protocol. I'm not completely sure why, but it seems like HTTP (which is also used for web page communications too), seems most commonly used for live streaming of video data, and UDP seems to be more applicable for transfer of files. I'm not sure which format is the fastest. With my Roku HD1000, HTTP streaming is significantly faster than UDP streaming, however with the Azbox, it seems like UDP is about twice as fast as HTTP, so I'm guessing that the differences must be mainly in the efficiency of the programs doing the streaming more than the specific protocols. BTW, there are a lot of data transponders on satellite that are sending IP/DVB type data, and if you have TSREADER, you can see the specifics of the transfers. Whenever you see a handfull of mac addresses with high IP#s, starting in the 224.x.x.x range or 239.x.x.x, these are often transfer of video by UDP format, whereas if you see a bunch of mac numbers sending in http format, it's usually regular internet transfers.
I am not sure about this, just guessing, but I get the impression that UDP is usually used within a LAN rather than over the internet, and is usually used for binary data, and I THINK that UDP involves less overhead of communications between sender and receiver, and may be a little less reliable relative to errors. I also think that UDP can be used to send to multiple receivers, but I have no idea of how that works. I do know that sometimes if you find a UDP stream on sat, that sometimes you can have that stream repeated over your network, and VLC can play the video if you key in the proper destination IP#, but usually you can't do this because the data is often in proprietary formats.
Anyway, I'm really confused by the differences between these two formats, because it seems like UDP would be better for streaming live video, but it seems like HTTP is what is used, and I don't have a clue why.

 

[crackt]

i think the easiest way to compare them is that if a server was streaming in http then it needs enuff bandwidth to run the stream to as many users that request it. with udp one stream is available to all people that request it. so http ='s "packets for everyone" and udp ='s "one packet for all".

crackt out,.

 

[B.J.]

i think the easiest way to compare them is that if a server was streaming in http then it needs enuff bandwidth to run the stream to as many users that request it. with udp one stream is available to all people that request it. so http ='s "packets for everyone" and udp ='s "one packet for all".

crackt out,.

Thanks. That was my original understanding of the difference, but I was confused since it seems that there are so many video streams using HTTP when the above really makes it seem like UDP would be much better, at least with respect to bandwidth. I guess though that it wouldn't be as good in situations where a viewer gets errors, since I'm assuming that a single stream for everyone would preclude requests for repeat packets?

 

[crackt]

Thanks. That was my original understanding of the difference, but I was confused since it seems that there are so many video streams using HTTP when the above really makes it seem like UDP would be much better, at least with respect to bandwidth. I guess though that it wouldn't be as good in situations where a viewer gets errors, since I'm assuming that a single stream for everyone would preclude requests for repeat packets?

udp would be good for streaming live events with a set start time. while http is suitable for streaming recorded tv episodes where individuals may want to start watching at an unknown time.

crackt out,.

 

[Babadem]

Strange, relative to the UDP streaming not working, because as I mentioned in msg#8 above, I switched to 4931 firmware and UDP streaming from VLC worked fine for me, and I had none of the issues on going back to Settings. It seems like perhaps it's the HTTP channels are what's messing things up. Either that, or problems begin once you try adding more sats or channels, which I haven't done yet. I'd really suspect the HTTP things are at fault, because I detected problems with the HTTP implimentation before. I can't find my post about it right now, but I do remember that to get HTTP channels created manually, ie not by using that text file, that, I had to put an extra digit in for the port number because the Azbox was apparently ignoring the last digit. And if these IP channels created via the text file are working, then perhaps the channel data file is being corrupted by the way the HTTP channels are stored. I also posted about not being able to make any sense out of the info that was being stored in the channel data file for the HTTP channels. Ie for the UDP channels, you could see the IP#s in the channel data retrieved by MAZ or Azbox-Edit, but the data saved for the HTTP channel (seemed that you could only store one manually) seemed like gibberish.

Anyway, it's strange that you couldn't do UDP with 4931, because it worked for me.

@ the highlighted:
I find that confusing too. What version of VLC are you using?

 

[Scott Greczkowski]

There were some great stations on IPTV that I watched on my AZbox but unfortunately they are gone now. I miss watching british tv live.

 

[ikki]

Correct me if I am wrong, but untill lately the problem with wide spread IPTV deployment has been with the back bone of the internet.

SO if my numbers are correct, and this is where I would like peer review, we have about 300 million people in the US and it takes about 6 megabytes to guarantee a perfect SD picture.

300 million * 6 = one billion eight hundred million

Which I believe is 1.8 Terrabytes. None the less, according to AT&T (Which is just one of the back bone providers) on October 23, 2008, they announced the completion of upgrades to OC-768 for their backbone.

OC-768 is a network line with transmission speeds of up to 39,813.12 Mbit/s (payload: 38,486.016 Mbit/s (38.486016 Gbit/s); overhead: 1,327.104 Mbit/s (1.327104 Gbit/s)).

My point of this, if you haven't fallen asleep by now, is that for most non rural areas in the United States and Canada IPTV should now be a reality.