Jump to content

Loss of Series Recordings - M3U


Spaceboy
Go to solution Solved by Luke,

Recommended Posts

CBers

Does the url or path to the m3u ever change?

No, just content, but channel names/numbers should remain the same.

Link to comment
Share on other sites

Spaceboy

I think I've done it both with the same path and name and different ones. Series recordings have never persisted though

Link to comment
Share on other sites

Yes and looking at the code I can already see this will cause everything to be treated as if it were brand new.

Link to comment
Share on other sites

Spaceboy

i set it up again with access 160517, scheduled a series recording. then renamed access160517 to access 160517 old and 210717 access to access 160517. emby always pointed at access 160517. then ran refresh guide.

 

some changes seem to be reflected in emby but not all. the main change i made between those was updating the sports channel names and adding in some new ones, i had to shift every channel by about 10 in the guide. some of the new channels have been added but not all, very few of the name changes seem to be reflected. tbh i may have found this before and gone to the method of using a completely new m3u to get around it.

Link to comment
Share on other sites

Currently, giving the m3u a new path or filename is not supported in terms of preserving data. If you give it a new path, then at that point it will be like it is a brand new setup.

Link to comment
Share on other sites

Spaceboy

Currently, giving the m3u a new path or filename is not supported in terms of preserving data. If you give it a new path, then at that point it will be like it is a brand new setup.

ok this time i think you've misread. i didnt change the path or filename as far as emby is concerned. i swapped one m3u with a second named identically and kept it in the same location. really i just changed the contents of the m3u. if you are saying that emby can't even handle this then i don't understand how you are updating the m3u, you will have to elaborate.

 

but it did work. the series recording was preserved.

 

but, not all changes to the m3u were reflected in emby

Link to comment
Share on other sites

All new channels will have been added but in general any customizations that can be done in emby will not be overridden by m3u data.

Link to comment
Share on other sites

CBers

I use the Smart IPTV app on my Shield TV's to watch Live sports, as the app just works.

 

All channels are loaded from your IPTV provider's M3U file via the SIPTV website and the channels are all numbered and grouped into categories.

 

I know you can't record with it, but if Emby could somehow do the same with the loading of the M3U file, it would be awesome.

Link to comment
Share on other sites

Spaceboy

All new channels will have been added but in general any customizations that can be done in emby will not be overridden by m3u data.

so the problem is the other fr I raised? To reflect changes to the m3u in emby Edited by Spaceboy
Link to comment
Share on other sites

maegibbons

All new channels will have been added but in general any customizations that can be done in emby will not be overridden by m3u data.

 

Hi

 

I think this is the wrong Logic.  The M3U should be king.  Take the instance on changing the tvg-id tag to point to a different or changed Schedules Direct channel ID.   In this instace, however,  I would expect series recordings to be dumped as you are changing guide data.  You would still want that re-imported in to Emby.  A simple Channel name Change should definately be re-imported but that should not require the series to be DUMPED. i.e the channel name should not be in the key of series recordings.

 

Perhaps you could have a "lock" function if someone did not want the re-mport behaviour

 

I feel that series recordings should be keyed to "channel-ID", "tvg-id" and of course program.  If the actual stream url changes then that should be allowed without dumping the series - you might just be changing providers but the actual channel-id and tvg ids would be the same.

 

The above comments are all based on how Emby channel management is now.  If the managability of channels was easier in Emby then the need for importing from m3u would be less.  At the moment the most straighforward way is to manipulate the m3u directly which is why it should be king in relation to updates.

 

Krs

 

Mark

  • Like 2
Link to comment
Share on other sites

Spaceboy

Hi

 

I think this is the wrong Logic. The M3U should be king. Take the instance on changing the tvg-id tag to point to a different or changed Schedules Direct channel ID. In this instace, however, I would expect series recordings to be dumped as you are changing guide data. You would still want that re-imported in to Emby. A simple Channel name Change should definately be re-imported but that should not require the series to be DUMPED. i.e the channel name should not be in the key of series recordings.

 

Perhaps you could have a "lock" function if someone did not want the re-mport behaviour

 

I feel that series recordings should be keyed to "channel-ID", "tvg-id" and of course program. If the actual stream url changes then that should be allowed without dumping the series - you might just be changing providers but the actual channel-id and tvg ids would be the same.

 

The above comments are all based on how Emby channel management is now. If the managability of channels was easier in Emby then the need for importing from m3u would be less. At the moment the most straighforward way is to manipulate the m3u directly which is why it should be king in relation to updates.

 

Krs

 

Mark

i think this has to be a prime area of focus when you start looking at channel management. Its going to solve a number of problems immediately
Link to comment
Share on other sites

  • 2 months later...
Spaceboy

so @@Luke were you able to determine whether the changes you made in regard to series recordings affected this issue? i the other thread you referenced linking the series recordings to tvgid which is exactly what @@maegibbons is suggesting above. thanks

Link to comment
Share on other sites

Those other changes are unrelated and only applicable to hd homerun. I don't believe there is any open issue here at this point. If you run into an issue I'm happy to investigate. Thanks.

Link to comment
Share on other sites

Spaceboy

Those other changes are unrelated and only applicable to hd homerun. I don't believe there is any open issue here at this point. If you run into an issue I'm happy to investigate. Thanks.

well the issue, as you know from personally testing it, is that you can neither

 

-Update channels with a new m3u without losing series recordings

-Or get Emby to reflect all changes within an identically named and located m3u

 

We have discussed, and it is outlined above, that for iptv the content of the m3u should dictate everything else. That Emby does not do that is the issue

Link to comment
Share on other sites

 

 

Update channels with a new m3u without losing series recordings

 

Can you be more specific? because you should be able to change anything so long as the tvg-id's are staying the same, and not lose series recordings.

Link to comment
Share on other sites

Spaceboy

Currently, giving the m3u a new path or filename is not supported in terms of preserving data. If you give it a new path, then at that point it will be like it is a brand new setup.

well have you made changes since you made this statement because we are under the impression that this is the status quo?
Link to comment
Share on other sites

Spaceboy

ok that would still be true. i thought we were talking strictly the contents of the m3u.

but then that brings into play the second statement I made, that Emby won’t accept updates from the m3u even if it is only the contents that change, because you have Emby believing that it knows better than the m3u the user is loading. Changed channel names and logos do not update leaving a complete mess in the guide

 

It may be true that some users value being able to manually rename their live tv channels (although I really doubt this) but for iptv this should not be the case. Currently the only way you can update channel details from a new m3u is to reset up every single series recording. It would greatly improve the user friendliness of Emby if this could be changed.

Edited by Spaceboy
  • Like 1
Link to comment
Share on other sites

Spaceboy

and again we get to the point when i finally think you understand the problem and may be giving some consideration to thinking about working on it but your lack of response probably just means its either too complicated or its just not a priority at the moment. for me this is the biggest weakness of emby's approach to fixing problems and the +1 method of upvoting requests. the users are left completely in the dark as to whether you have even read the post, whether you have but don't agree there's an issue, where you agree there is an issue but you don't know how to fix it, or where you do but its not a priority at present

 

@@Luke you know admitting one's shortcomings is the first step to doing something about it? will you please acknowledge this issue at least so we don't have to go through this complete palaver in 3 months time when again there has been no activity. 

Link to comment
Share on other sites

maegibbons

Specifically you should be able to change the Logo, the name and the stream URL whilst keeping the tvg-id the same.

 

These changes in the m3u file should be brought in to emby on a restart WITHOUT droping scheduled recordings against the tvg-id as it is the same.

 

I wrote before "m3u should be king" in terms of CURRENT Name, Logo and URL for the same tvg-id.

 

Krs

 

Mark

  • Like 1
Link to comment
Share on other sites

and again we get to the point when i finally think you understand the problem and may be giving some consideration to thinking about working on it but your lack of response probably just means its either too complicated or its just not a priority at the moment. for me this is the biggest weakness of emby's approach to fixing problems and the +1 method of upvoting requests. the users are left completely in the dark as to whether you have even read the post, whether you have but don't agree there's an issue, where you agree there is an issue but you don't know how to fix it, or where you do but its not a priority at present

 

@@Luke you know admitting one's shortcomings is the first step to doing something about it? will you please acknowledge this issue at least so we don't have to go through this complete palaver in 3 months time when again there has been no activity. 

 

This is where I fear we have set way too high of an expectation for support.  Is there any other software company you have ever dealt with where you demanded that level of detail into their thinking less than 12 hours after making a statement (between the hours of 6pm and 5am for the company as well)?

 

I promise you that either Luke, I or (usually) both of us read all the posts out here and try to respond when we have something substantive to say.  Sometimes when we don't respond it is because we have to think about it for a bit first (or maybe even sleep a bit).  Sometimes we don't respond to what we may think is a "no-brainer" just because it takes time to respond to every single topic out here and we do want to do things other than respond to topics :).  But we do still try to respond to every one of them in time.

 

I also promise you that we have very long lists of things to work on and we have to juggle all of them.

 

We are working as hard as we can and trying to make everyone as happy as possible.

 

Thanks.

Link to comment
Share on other sites

Spaceboy

@@ebr no I’m talking about revisiting this thread three months after I thought we had agreed there was an issue to find out that we’re still not clear if there is an issue. Don’t obfuscate things with reference to a 12 hour SLA. I’ve been with you guys for 10 years plus. I know a 12hour SLA is completely unreasonable. I do expect a little bit of certainty after 3 months though.

 

Perhaps you and Luke should have read a little more than the last one or two posts before responding?

 

Final edit, there doesn’t seem to be any delay in denying an issue, perhaps the same approach could be taken to acknowledging them? Not asking for commitment, a simple “I agree” would be sufficient

Edited by Spaceboy
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...