GSoC/2017/StatusReports/ahmedfathy
- Hupnp_av code. useful for viewing codes and moving through them as the offline version is not connected to a project https://code.woboq.org/kde/extragear/graphics/kipi-plugins/dlnaexport/hupnpmediaserver.cpp.html
Very useful documentation for me for Hupnp
file:///home/ahmed/Downloads/herqq-1.0.0/hupnp/docs/html/builddevice_tutorial.html file:///home/ahmed/Downloads/herqq-1.0.0/hupnp/docs/html/group__hupnp__devicemodel.html#_details file:///home/ahmed/Downloads/herqq-1.0.0/hupnp/docs/html/group__hupnp__devicehosting.html file:///home/ahmed/Downloads/herqq-1.0.0/hupnp/docs/html/class_herqq_1_1_upnp_1_1_h_device_host.html
Upnp Full specs document /home/ahmed/Downloads/upnpresources/documents
Nodejs library -> tested on my machine
https://www.npmjs.com/package/peer-upnp
Pupnp library -> /home/ahmed/upnp-different-libraries-test/pupnp/pupnp
---
9/6 During the last period, I have done a lot of reading both for the Upnp standard and some of its implementations in javascript (node) and c++ . I connected my computer to my android phone using SSDP using some libraries. this might be a small step, but It actually means I got the grasp of what I will actually be doing in the coming days. my goal next is to make my own stand alone ssdp QT code that will be part of the actual standalone server I will implement for the final project.
I compiled Hupnp library in QT5 now and fixed issues as they arose. I decided to use this and not write from scratch. I will implement the standalone server using Hupnp ( the ported edition ) source code DIRECTLY, no linking etc.. Simple communication between my computer and my SSDP tracer on my android let me know that the mobile did discover the Hupnp media server which is a good step forward. I hope to finish the stand alone server before the first evaluation deadline, but If I couldn't, it will not be long after that.
progress for the past three weeks :
Well, I went through a lot in the previous period. After I compiled and used Hupnp library as a basis for the media server, It turned out to work with some media clients and not work with others. This was half promising (because it worked) and half sad (because of the clients it didn't work well with).
Applications that worked include : 1- BubbleUpnp (Android) 2- VLC (Android) 3- MediaHouse (Android) 4- AnDLNA (Android)
These four work as expected. sometimes I have to wait for about 40 seconds before they discover the Hupnp server but they eventually do , without restarting.
I also tested the following, which seemed to have problems:
5- ginkoDlna (Andriod) 6- Upnplay (Android) 7- vlc (PC version) 7- gupnp-av (PC)
I spent a quite large amount of time investigating these problems to find out wether the problem was with them or with Hupnp. I figured out that ginkoDlna works only with specific file formats (without explicitly telling so or raising warnings or errors, just stops, that's why initially I categorized it as not working). using the supported files it worked, so the bad list shrinked to three.
As for Upnplay, I found out that for some reason it does not send standard http requests, it doesnot end the header with double new lines "\r\n\r\n" , while hupnp waited for this specific sign to continue working properly. so this is a upnplay problem, not mine. I moved on.
For VLC (PC) I spent some time also to figure out the problem. I decided to build its code myself and to my surprise it worked !. That is when I realized that my installed version of vlc was not the latest git version. I installed the latest git version for VLC and it turned out to work perfectly. Don't know whose mistake is that :D
The strangest part happened with gupnp-av. As usual, I spent some days trying to figure out why it didn't work, cloned and built their C code my self and started debugging both the apps against each other.
I noticed that: For the applications that do work well with Hupnp, they send two upnp browse action requests , one for "BrowseMetaData" , followed by "BrowseAllChildren" after Hupnp sends the response. As for Gupnp-av , it only sends "BrowseMetaData" without the other browse request. I checked that the response to "BrowseMetaData" from Hupnp to Gupnp arrives successfully and as expected.
After a while with no further progress as to WHY the second request was not being sent, I decided to ask the gupnp developers directly. I asked on their IRC .They were really helpful. one of them , Jens Georg <[email protected]> , told me it was a bug in gupnp-av control point. it DOES NOT WORK if I don't place an icon for my dlna server ! So I just put an icon image for the hupnp server and it did work perfectly !
At this point I considred Hupnp to be sufficiently reliable to continue with, working with various clients without problems. I was ready to start the second phase : integrate into digikam.
I started integrating the new version of hupnp into digikam. I again spent a while figuring out how to work with the cmake file system (instead of qmake the default for qtcreator) . after that I spent another while solving all the issues that popped into me after this integration. some were cmake issues and some were qt5 issues, and some were kde standard issues. I actually spent some days solving those until I managed to start the server as part of digikam ! This is the core part of my work finished here, all that remains is improvements .
After that, I added the save-load feature to the server as proposed in my gsoc proposal. now the folders that the user places as shared by the dlna server inside digikam are saved on the application close and automatically restored and announced when it is opened again. The user also can delete folders and items as he wishes.
This is where I stand right now ( 18th july ). In the remaining time I need to add some ui features for the server in digikam, add setup configurations, neatly organize the cmake files I added as they are not quite organized (despite working properly) , testing digikam on other operating systems, fixing the issues as they arise, completing documentation and finalizing my work.
final report - 27 Aug - 2017 -----
Today I have finished my work on the dlna project and I am satisfied with the results. I added the features I wanted, and placed the starters of the server in approporiate positions inside digikam app. I also created the server configuration panel, which gives the user the choice to 1) start the server automatically on startup or not and 2) start it in the background or in the foreground. those settings are saved of course. I also written the documentation and the how to use sections in the handbook of digikam. I am ready for final evaluation. This is the link of my branch I have my final work on ::- https://github.com/KDE/digikam/tree/gsoc17-dlna
It has been a nice experience working at digikam !