Does anyone have any time related issues with the BuzzTV epg? What I'm seeing is that with the latest update we have the ability to offset the epgtime which works for some channels but not others. I set the epg offset to what works for most channels but there are quite a few that are still off by an hour or more. I switch over to the z7+(same service) and the epg is correct for all channels but the BuzzTV, some are correct time and some are not, so it's not related to the service. I use multiple portals and the same behaviour exists for all. Anyone else? Any ideas?
BuzzTV EPG Issue
- Thread starter Znix
- Start date
I've been using the nfps iptv service since 2015, and there was a time back in 2015-2016 where the EPG worked most of the time, but this same, repetitive & annoying EPG issue has really become increasingly annoying over the past year.
I recently acquired a BUZZTV XPL3000 with Android v7.1.2 pre-installed on it, and after disabling the Automatic date & time / Use Network provided time option in the Settings->Date & Time sub-menu, and then trying all kinds of EPG tome-offset values from within the Configuration->EPG time offset settings page located elsewhere within the dizzing array of menus/options/sub-menus within the unit, I too can report I couldn't get the EPG to show proper times for any of the shows listed either.
That said, I'm not sure how this feature could account for all of the different time offfsets associated with the source content itself, when the source content isn't all off by 4 hours or whatever the case may be from one day/week to the next (i.e, most shows are off by 4 hours for my timezone/location, while others appear to be off by 2 hours).
@Znix:
You stated in the opening post of this thread that you'd also tried the EPG time offset feature on another stb (DL Z7+) on the same iptv service as the BuzzTV XPL3000 stb, and that other stb's EPG Time Offset feature seemed to correctly handle this annoying EPG issue, which intrigued me as to how that unit's software algo's were able to accomplish that feat. I'm considering acquiring one of those other stb's too, just for fun, and hopefully I'll have similar results as you reported to have had.
Meanwhile, I'm still familiarizing myself with the myriad of choices & features the BuzzTV XPL3000 stb has to offer, and I'm making a very short list of feature changes/requests I intend to submit for the xpl3000 shortly, mainly nit-noid stuff like sub-par (weak) RCU reception on the stb itself (on mine it requires laser-guided aim for the remote to be seen/recognized, even with fresh batteries), and slow channel changing in full screen mode using the up/down arrow keys, and of course, the EPG time offset feature not working properly...but overall I do like this new BuzzTV XPL3000 box...yup!
I recently acquired a BUZZTV XPL3000 with Android v7.1.2 pre-installed on it, and after disabling the Automatic date & time / Use Network provided time option in the Settings->Date & Time sub-menu, and then trying all kinds of EPG tome-offset values from within the Configuration->EPG time offset settings page located elsewhere within the dizzing array of menus/options/sub-menus within the unit, I too can report I couldn't get the EPG to show proper times for any of the shows listed either.
That said, I'm not sure how this feature could account for all of the different time offfsets associated with the source content itself, when the source content isn't all off by 4 hours or whatever the case may be from one day/week to the next (i.e, most shows are off by 4 hours for my timezone/location, while others appear to be off by 2 hours).
@Znix:
You stated in the opening post of this thread that you'd also tried the EPG time offset feature on another stb (DL Z7+) on the same iptv service as the BuzzTV XPL3000 stb, and that other stb's EPG Time Offset feature seemed to correctly handle this annoying EPG issue, which intrigued me as to how that unit's software algo's were able to accomplish that feat. I'm considering acquiring one of those other stb's too, just for fun, and hopefully I'll have similar results as you reported to have had.
Meanwhile, I'm still familiarizing myself with the myriad of choices & features the BuzzTV XPL3000 stb has to offer, and I'm making a very short list of feature changes/requests I intend to submit for the xpl3000 shortly, mainly nit-noid stuff like sub-par (weak) RCU reception on the stb itself (on mine it requires laser-guided aim for the remote to be seen/recognized, even with fresh batteries), and slow channel changing in full screen mode using the up/down arrow keys, and of course, the EPG time offset feature not working properly...but overall I do like this new BuzzTV XPL3000 box...yup!
I posted a solution a couple of days ago.
Install Perfect Player
Make a Custom Playlist file using the Templates in m3u section.
Use my EPG guide URL.
You use Perfect Player for TV watching, with a guide that is working as it should (the right time!).
Only use DOL for access to VOD.
* Just a workaround until they fix there problem.
/kens
Install Perfect Player
Make a Custom Playlist file using the Templates in m3u section.
Use my EPG guide URL.
You use Perfect Player for TV watching, with a guide that is working as it should (the right time!).
Only use DOL for access to VOD.
* Just a workaround until they fix there problem.
/kens
@kens:
Thanks...I happened to have read that thread with ur input/method posted in it recently too. Interesting stuff.
I haven't messed around with playlists and the lot, opting to just go with the iptv service provider/recommended box choice method, which has, up until lately, worked adequately.
(I guess having said that, and in light- of alternatives such as the ones you've posted, I have only myself to be annoyed with for being lazy! LoL)
I do appreciate your continued insights and ongoing efforts to contribute/assist the community...good stuff!
Thanks...I happened to have read that thread with ur input/method posted in it recently too. Interesting stuff.
I haven't messed around with playlists and the lot, opting to just go with the iptv service provider/recommended box choice method, which has, up until lately, worked adequately.
(I guess having said that, and in light- of alternatives such as the ones you've posted, I have only myself to be annoyed with for being lazy! LoL)
I do appreciate your continued insights and ongoing efforts to contribute/assist the community...good stuff!
Just an Example... If the Server is located in Time Zone at (-)1 Hour and it gets a Feed from say (-)6 Hour Time Zone, what would the Time be Shown in a (-)4 Hour Time Zone...?!?
not sure what you mean but I have never had a time issue using a buzz
don't even need to use offset
Simple, are the Owners of the STB's Manually Changing the Time Settings when They Input Their Location...?!?
EPG time data is indeed sent from the server but it's sent in UTC and it's up to the app/stb to convert it to the proper timezone set by the OS. Somewhere in the buzztv app there is a bug that fubars this conversion in a small amount of channels. What seperates those channels from the others and why it only happens some settups and not others is the question. I frequent the vaders telegram channel where thousands of users go through there every day and lots of buzztv users but only a small percentage of them have this issue.
The question is, the small percentage of users having this issue what service are they using. I have tested some other services and only have this issue with this service. I'm not convinced it's the Buzz box. The three services only resale Papiao which is the main server. From what I can gather, Papiao is pulling channels/guide data from other sources, meaning they are not the original source of the feed and have no control over the data; they just refeed it to us. When a channel goes black Papiao does not call the guy feeding the source because they don't know who they are. They just have to wait until whoever on the other end feeding the channel fixes it. Because there are multiple sources of data, the guide information is being fed differently for some channels than others depending on where it comes from and who's sending it. This cannot be fixed by the "server" because they are not in control of the data.
I could be wrong, but everything points to multiple feeds from fourth party sources which I believe is the crux of the issue. In order for the time offset feature in the Buzz box to work properly each channel would have to be offset independently.
Last edited:
@Znix, PayPerView, and kens:
Thank you for ur input, and to a certain extent, helping making this issue more salient than it has been for quite a while, IMHO.
@dishuser:
Yes..I understood ur point in this thread and elsewhere...and...while it appears u chose to avoid answering my Q regarding whether or not ur using nfps/papaio for iptv service, and that's ok, cuz I've surmised ur not based on ur replies/posts elsewhere here on this site regarding ur apparent lack of issues with EPG Time accuracy, which is cool, I get it..ur saying the server is where the EPG Time issue lives, or where it's supposed to be handled correctly from in the first place.
@everyone:
I admit to not having dug more deeply into the mech[anics of how the EPG Timecode process works, like some of the more informed tech gurus/subject matter experts like site member kens and a few others here have...but will strive to peel the onion until I do have a better grasp of how this important function is supposed to work, and therefore be able to pose more intelligent questions to NFPS and the team as to why this issue keeps coming up over and over, year after year.
That said, after researching a bit further on the input from kens regarding a temporary work-around solution, both in this thread, and identically in another, as it pertained to using playlists and an external guide source (.xml file), which when combined with the experience Znix stated he'd had in this thread with another stb (DL Z7+), the concept of perhaps enabling the end user to use alternative EPG sources especially peaked my curiosity. Perhaps the BUZZTV software developers could implement support for the external EPG .xml file like the DL Z7+ software development team has.
Again, I'm just embarking on my journey / quest to more thoroughly understand how the EPG Data acquisition process works, including Time Domain and Referential Time Code Integrity checking, but it has made me wonder why the process being used in kens method could not be employed / implemented at the server level, and simply referenced via a field in the stb, unless manual upkeep of the playlist equivalent of a server-wide channel list / server-wide .xml EPG file would be too labor intensive.
Thank you for ur input, and to a certain extent, helping making this issue more salient than it has been for quite a while, IMHO.
@dishuser:
Yes..I understood ur point in this thread and elsewhere...and...while it appears u chose to avoid answering my Q regarding whether or not ur using nfps/papaio for iptv service, and that's ok, cuz I've surmised ur not based on ur replies/posts elsewhere here on this site regarding ur apparent lack of issues with EPG Time accuracy, which is cool, I get it..ur saying the server is where the EPG Time issue lives, or where it's supposed to be handled correctly from in the first place.
@everyone:
I admit to not having dug more deeply into the mech[anics of how the EPG Timecode process works, like some of the more informed tech gurus/subject matter experts like site member kens and a few others here have...but will strive to peel the onion until I do have a better grasp of how this important function is supposed to work, and therefore be able to pose more intelligent questions to NFPS and the team as to why this issue keeps coming up over and over, year after year.
That said, after researching a bit further on the input from kens regarding a temporary work-around solution, both in this thread, and identically in another, as it pertained to using playlists and an external guide source (.xml file), which when combined with the experience Znix stated he'd had in this thread with another stb (DL Z7+), the concept of perhaps enabling the end user to use alternative EPG sources especially peaked my curiosity. Perhaps the BUZZTV software developers could implement support for the external EPG .xml file like the DL Z7+ software development team has.
Again, I'm just embarking on my journey / quest to more thoroughly understand how the EPG Data acquisition process works, including Time Domain and Referential Time Code Integrity checking, but it has made me wonder why the process being used in kens method could not be employed / implemented at the server level, and simply referenced via a field in the stb, unless manual upkeep of the playlist equivalent of a server-wide channel list / server-wide .xml EPG file would be too labor intensive.
For me, this happens with 5 completly different services and none are resellers of each other or the same service. In fact, it happens with every service I use on the box. The epg timing is correct on all apps running on the buzztv box except the buzztv app. My formuler boxes with MOL do not have this issue with the same services. Everything points to the buzztv app but there is a variable as to why it does not affect all buzztv app users. Possibly timezone, some combination of settings or maybe a specific hardware revision...or something else.