| rhpot1991 | superm1: tgm4883 mrand dmfrey wants to report a bug for the user's groups, where should that go | 17:48 |
|---|---|---|
| tgm4883 | the users group? | 17:49 |
| dmfrey | just wanted to see if dialout could be added to the main users groups by default | 17:50 |
| rhpot1991 | he says it should be in the dial out group for access to libcec | 17:50 |
| dmfrey | libcec is for access to the usb cec adapters | 17:50 |
| dmfrey | i also noticed that the ChannelIcons storage group is not being created, so no channel icons are downloading | 17:51 |
| tgm4883 | is that a new storage group? | 17:51 |
| tgm4883 | I don't remember that one | 17:51 |
| dmfrey | i was looking into why my channel icons weren't showing on new 12.04 backend install | 17:52 |
| dmfrey | i guess they used to be in ~.mythtv/channels | 17:52 |
| dmfrey | but the documentation seems to indicate they should now be in (in mythbuntu) /var/lib/mythtv/channels and mythfrontend looks for them in the Storage group ChannelIcons | 17:53 |
| tgm4883 | Bugs go at https://bugs.launchpad.net/mythbuntu/+filebug | 17:53 |
| Zinn | [bugs.launchpad.net] OpenID transaction in progress | 17:53 |
| tgm4883 | why does libcec need dialout? | 17:53 |
| dmfrey | that is the group the /dev/ttyACM0 device gets created into | 17:54 |
| dmfrey | pulse-eight usb cec adapter | 17:54 |
| tgm4883 | Does that group make sense for that device? | 17:54 |
| tgm4883 | secondly, does the device need to be accessed by the frontend or backend? | 17:57 |
| dmfrey | not sure if it makes sense, i will ask in the pulse-eight channel if that is preferred | 17:59 |
| dmfrey | it is accessed in the frontend | 17:59 |
| dmfrey | if you don't have libcec installed, you usually see 'cecadapter.cpp:128 (Open) CECAdapter: Failed to load libcec.' in the logs | 17:59 |
| superm1 | dmfrey: does the backend user need to be in it or the frontend user? | 18:06 |
| tgm4883 | superm1, sounds like frontend user | 18:06 |
| dmfrey | frontend | 18:06 |
| superm1 | dmfrey: hmm well the default user ubuntu creates gets put in the dialout group | 18:07 |
| dmfrey | weird, mine wasn't in there | 18:09 |
| dmfrey | this was a fresh install from sunday night | 18:09 |
| dmfrey | i check both my machines, fresh install from sunday night and monday morning, one is x86_64, other is 32 pae and neither have dialout in the groups | 18:16 |
| superm1 | hmm weird, what did you install from? | 18:16 |
| superm1 | mythbuntu ISO or ubuntu ISO or ubuntu server ISO | 18:16 |
| dmfrey | mythbuntu iso | 18:19 |
| superm1 | hmm weird | 18:37 |
| dmfrey | ok, i had to not only add libcec but libcec-dev to get mythfrontend to recognize that libcec was installed | 18:43 |
| dmfrey | went looking through the cecadapter.cpp and saw the libcec headers it was trying to load which were not on my system | 18:46 |
| dmfrey | installing the dev package fixed that | 18:46 |
| tgm4883 | dmfrey, I think I'm too invested in this email thread for a project I don't even work on | 19:00 |
| rhpot1991 | tgm4883: welcome aboard | 19:02 |
| tgm4883 | rhpot1991, yea, I'm kinda tired of people that demand things for free | 19:04 |
| rhpot1991 | I'm tired of visual studio crashing | 19:05 |
| dmfrey | rhpot1991, shoot me now, haven't looked at visual studio in over 10 years :) | 19:07 |
| dmfrey | tgm4883, yeah, i am not sure what he thinks that will do that something like mythexport doesn't already do | 19:07 |
| dmfrey | plus the app would in essence have to watch the program for your in order to download and store, it would still need to kick off a hls stream | 19:08 |
| dmfrey | my last email pretty much says it is not gonna do it | 19:08 |
| tgm4883 | dmfrey, I think he just wants it more integrated, which would probably be great, but would require a lot more on the app side and probably still be clunky | 19:08 |
| tgm4883 | yea my last email basically says patches probably welcome | 19:08 |
| rhpot1991 | I misunderstood what he was asking I guess | 19:09 |
| rhpot1991 | I though the wanted to access recordings without transcoding | 19:09 |
| rhpot1991 | the problem with local storage is that its anti HLS too | 19:10 |
| tgm4883 | rhpot1991, he doesn't want to wait for transcoding | 19:10 |
| tgm4883 | so no mythexport, yes HLS | 19:10 |
| rhpot1991 | in theory we could prob wget it all, modify the playlist and have it pull from local | 19:10 |
| dmfrey | i am not sure that you could record the hls stream to a file in java anyway | 19:10 |
| rhpot1991 | playlist isn't done until the transcoding is done too | 19:10 |
| tgm4883 | dmfrey, could you just store the file chunks? | 19:10 |
| rhpot1991 | so you can't pull till everything is done | 19:10 |
| tgm4883 | as rhpot1991 said, store the m3u8 file, alter it for local playback of the file chunks, and be on your way? | 19:11 |
| rhpot1991 | not a great solution due to things I just said though | 19:12 |
| tgm4883 | rhpot1991, I don't like the timeframe of it, taking super long to actually get the files needed | 19:12 |
| tgm4883 | rhpot1991, I think it's perfectly fine though size wise | 19:12 |
| dmfrey | tgm4883, i don't think so, since they are offloaded to an external player | 19:12 |
| rhpot1991 | tgm4883: ya I thought he wanted no transcoding which leads to huge files | 19:13 |
| tgm4883 | dmfrey, well what do you do right now? You download the m3u8 file and hand it to VIDPLAYER? | 19:13 |
| tgm4883 | rhpot1991, no he wants HLS to transcode it | 19:13 |
| rhpot1991 | tgm4883: ya | 19:13 |
| rhpot1991 | get the playlist via the api call | 19:13 |
| tgm4883 | rhpot1991, even then, except for nexus devices I don't think size matters ;) | 19:13 |
| rhpot1991 | pump that to the player | 19:13 |
| rhpot1991 | who handles the rest | 19:13 |
| rhpot1991 | tgm4883: well even if you max out with a 32gb card | 19:14 |
| rhpot1991 | thats maybe 2-3 large recordings | 19:14 |
| rhpot1991 | I was going to explore doing some local non transcoding with google tv possibly | 19:14 |
| tgm4883 | rhpot1991, I think that is probably all you need, but if you HLS transcode it you should get more | 19:14 |
| rhpot1991 | if you are local and it can handle your content no reason you need ot transcode | 19:14 |
| tgm4883 | rhpot1991, dmfrey so what if you download the m3u8 file to a cache dir, edit it, then hand it over to VIDPLAYER? | 19:15 |
| rhpot1991 | tgm4883: its built as the transcoding happens I believe | 19:15 |
| rhpot1991 | so you'd have to wait till all transcoding was done | 19:15 |
| rhpot1991 | get it then, modify, use | 19:15 |
| dmfrey | but soon they will be introducing an ondemand hls | 19:15 |
| tgm4883 | ondemand? | 19:15 |
| dmfrey | you will literally be able to jump to a specific spot in the program | 19:15 |
| tgm4883 | isn't it already on demand? | 19:16 |
| tgm4883 | ah | 19:16 |
| dmfrey | it will all be coded into the rest endpoint | 19:16 |
| tgm4883 | that will be nice :) | 19:16 |
| dmfrey | including video size, bitrate, etc | 19:16 |
| tgm4883 | then you could do what netflix does I'm guessing | 19:16 |
| tgm4883 | adjusting bitrate on the fly? | 19:16 |
| dmfrey | pretty much | 19:16 |
| dmfrey | could possibly | 19:16 |
| dmfrey | until i see it, i am not sure | 19:16 |
| dmfrey | probably be in on .27 | 19:16 |
| tgm4883 | I'm assuming there is still file storage though on the backend for HLS transcodes | 19:17 |
| dmfrey | if not .28 | 19:17 |
| dmfrey | i assume so. in the streaming storage group | 19:17 |
| dmfrey | now that i think about it, we could probably make the app kick off a hls stream, so that it pre-transcodes on the backend, then you can come to it whenever you want | 19:18 |
| dmfrey | right now we start it, wait, then play it | 19:18 |
| dmfrey | when done, we kill the stream | 19:18 |
| dmfrey | on the backend | 19:18 |
| tgm4883 | yea I think the main issue is the transcoding time | 19:19 |
| dmfrey | could almost implement a watch it later feature so it is already transcoded on the backend | 19:19 |
| dmfrey | then should be able to ff and rew | 19:19 |
| dmfrey | that might be something to think about | 19:19 |
| dmfrey | i gotta get my data loading issues solved first | 19:19 |
| dmfrey | so its not so slow for people | 19:20 |
| tgm4883 | dmfrey, if you did a watch it later feature, you could make that a prerequiset of 'download locally" | 19:20 |
| dmfrey | true | 19:20 |
| tgm4883 | so with the data loading issues, you are pulling the entire schedule? | 19:21 |
| dmfrey | not sure if the myth services api allows for downloading the .m3u8 files themselves | 19:21 |
| dmfrey | the first time through, i load each day at a time, then parse it to a db | 19:21 |
| tgm4883 | is that really necessary? | 19:21 |
| dmfrey | that is for implementing a youtube like search from the action bar | 19:21 |
| tgm4883 | hmm | 19:22 |
| dmfrey | like mythweb does it | 19:22 |
| dmfrey | i don't want to be constantly accessing the the backend | 19:22 |
| dmfrey | my thought now is to download hour chunks and store them as json | 19:22 |
| dmfrey | use that for the program guide when you page through the hours and days from local files | 19:23 |
| tgm4883 | dmfrey, well, I only think you need it locally if you want to have offline searching | 19:23 |
| tgm4883 | which I don't think is needed | 19:23 |
| dmfrey | implement etag into them so i know when data changes to redownload a chunk here and there | 19:23 |
| tgm4883 | what if there was a services API for searching the schedule? | 19:23 |
| dmfrey | i didn't find one | 19:23 |
| tgm4883 | right, I meant if one was added | 19:24 |
| dmfrey | maybe it will be added, but don't think that is available now | 19:24 |
| tgm4883 | probably right | 19:24 |
| tgm4883 | similar to the "list titles" being unavailable | 19:24 |
| dmfrey | in the /Guide services, you can get the program guide, get details for a particular program, or the channel icon | 19:25 |
| dmfrey | yeah | 19:25 |
| dmfrey | maybe in the /Dvr GetFilteredProgramList, but that might be for just what you have recorded already | 19:25 |
| tgm4883 | yea that is just what is recorded already | 19:25 |
| tgm4883 | and that returns way too much info IMO | 19:26 |
| dmfrey | so, following android design guidelines, download data locally, store in content provider, only access network when needed | 19:26 |
| tgm4883 | ah | 19:27 |
| dmfrey | pretty much to save battery, etc. | 19:27 |
| tgm4883 | that changes things | 19:27 |
| dmfrey | global search needs content provider | 19:27 |
| dmfrey | so if i keep the files locally, i can use them, parse them when needed, etc. | 19:27 |
| dmfrey | setup alarm tasks to delete old stuff | 19:27 |
| dmfrey | and, once etag is publicly available, can use that to determine of the network resource changed and only download when needed | 19:28 |
| dmfrey | i like json for local storage because i can parse that in java much faster than xml | 19:29 |
| dmfrey | plus for the program guide i put in the latest version, the data is already structured in the format i need to move through that pager | 19:30 |
| dmfrey | and have been reading up on managing some caches of files for quicker ui/ux response | 19:31 |
| dmfrey | could prove to be quite a fast interface | 19:31 |
| dmfrey | so basically when you start the app, start downloading the data chunks in the background and let you do whatever you want in the app | 19:32 |
| tgm4883 | right, which makes sense | 19:32 |
| dmfrey | however, you will only be able see the data up to the point where you downloaded it | 19:32 |
| dmfrey | which i think is acceptable | 19:32 |
| tgm4883 | which I think is reasonable | 19:32 |
| dmfrey | since it will eventually fill in everything | 19:32 |
| tgm4883 | exactly | 19:35 |
| tgm4883 | so probably just grab the more often used stuff first | 19:35 |
| tgm4883 | probably schedules last | 19:35 |
| dmfrey | right | 19:36 |
| rhpot1991 | ignore where type == reality tv | 19:49 |
| rhpot1991 | populate with breaking bad instead | 19:49 |
| dmfrey | :) | 19:49 |
| kenalex | hello | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!