Skocz do zawartości

Dosyły Polskiego Radia dla FM z 7°E namierzone


Mr. Orbita
 Udostępnij

Rekomendowane odpowiedzi

Od dawna wiadome było, że Polskie Radio puszcza dosyły do nadajników naziemnych cyfrowo z satelity - z 7°E (gdy były awarie to i były przerwy), ale nikt nie wiedział ani gdzie, ani w jakim formacie. EmiTel dzielnie nie zdradzał tego sekretu, PR też nie i tak sobie to trwało ;)

 

Nie jestem pewny, ale chyba właśnie je namierzyłem :D Niestety nie posłuchamy (no najwyżej jak ktoś wpadnie na pomysł jak odtworzyć strumień IP).

 

Przekaz Polskiego Radia leci w zwykłym DVB-S z tp. F4 (12,633 GHz, pol. V, SR: 1084, FEC: 3/4). Ta częstotliwość była znana już od dawna, ale jako dane. W 2011 roku zgłosił ją do Flysata @rysiuhelix ;)

 

Okazuje się, że w środku kryje się paczka Polskiego Radia jako DVB-IP. Nadawanych jest 5 stacji (i jest jeszcze nieco miejsca wolnego)

 

PID 2010 = Jedynka IP: 192.168.30.121 (nazwa: JedynkaSpare, tytuł: Spare_MPEG4_128/48_St), przepływność na PID: ok. 234,94 kbit/s

PID 2020 = Dwójka IP: 192.168.30.122 (nazwa: DwojkaSpare, tytuł: Spare_MPEG4_128/48_St), przepływność na PID: ok. 248,75 kbit/s

PID 2030 = Trójka IP: 192.168.30.123 (nazwa: TrojkaSpare, tytuł: Spare_MPEG4_128/48_St), przepływność na PID: ok. 183,47 kbit/s

PID 2040 = Czwórka IP: 192.168.30.124 (nazwa: CzworkaSpare, tytuł: Spare_MPEG4_128/48_St), przepływność na PID: ok. 183,33 kbit/s

PID 2050 = PR dla Zagranicy (?) IP: 192.168.30.125 (nazwa: PoloniaSpare, tytuł: Spare_MPEG4_80/48_2CH), przepływność na PID: ok. 162,81 kbit/s

 

Napisałem wyżej, że nie jestem pewny, bo:

1) Jakość wydaje mi się jakaś nietęga, jeśli założyć dosył do nadajników, ale "MPEG4" w nazwach może wskazywać, że chodzi MPEG-4 Audio

2) W nazwach pojawia się "Spare" - zapasowy, może więc to tylko jakaś awaryjna wersja, a nadal coś jeszcze gdzieś się kryje, może w innej wersji?

3) Po co w paczce do emisji naziemnej byłoby PR dla Zagranicy?

 

Sygnał nie jest zbyt silny u mnie - 10,4 dB na 180 cm, coś kiepsko, poruszam może jeszcze anteną... Podobnie (DVB-IP) nadawana jest paczka Eurozet z 39°E...

Odnośnik do komentarza
Udostępnij na innych stronach

1) Jakość wydaje mi się jakaś nietęga, jeśli założyć dosył do nadajników, ale "MPEG4" w nazwach może wskazywać, że chodzi MPEG-4 Audio

W takiej jakości Polskie Radio dosyła swoje programy do nadajników naziemnych. Efekt oszczędności. Programy są kompresowane w zwykłym AAC (chyba nie AAC+).

 

2) W nazwach pojawia się "Spare" - zapasowy, może więc to tylko jakaś awaryjna wersja, a nadal coś jeszcze gdzieś się kryje, może w innej wersji?

Być może jest to zaszłość z czasów, kiedy programy nie były dosyłane tylko drogą satelitarną. Obecnie dosył światłowodowy mają tylko nieliczne obiekty.

 

3) Po co w paczce do emisji naziemnej byłoby PR dla Zagranicy?

Do nadajników średnio i krótkofalowych mieszczących się poza granicami kraju, z których nadawany jest program dla słuchaczy za granicą.

 

Jak masz możliwość, to strumień IP sprawdź WireShark-iem.

Odnośnik do komentarza
Udostępnij na innych stronach

Wydaje się, że faktycznie AAC. Kombinując na różne sposoby udało mi się wyciągnąć audio, ale poszatkowane, nie nadaje się do słuchania :/ Muszę nad tym posiedzieć, ale chwilowo nie mam pomysłu...

 

Na razie wydłubuję tak (Wireshark):

- otwieram cały TS (z całego transpondera)

- Telephony -> RTP -> Show All Streams

- wskazuję jedną ze stacji

- Save As

 

Jeśli w tym samym oknie wejdę w Analyze, to widać, że jest niedobrze:

Total RTP packets = 14027 (expected 14027) Lost RTP packets = 6781 (48,34%) Sequence errors = 6777

 

Ale straconych pakietów w środku w zasadzie nie ma (przy zapisie), więc nie wiem skąd losty i dlaczego są błędy sekwencji. Muszę zbadać sposób na 39°E, ale na razie mam co innego na głowie, wrócę do tego później.

Odnośnik do komentarza
Udostępnij na innych stronach

Nagrywanie całego TS: TSrecorder (dla TBS6925) oraz AltDVB, kontrola błędów na TransEdit. Próbowałem też pojedyncze PID-y przez TransEdit, ale wygląda, że jest to niewystarczające, bo wycinając zbędne pakiety dostaje się śmietnik. Strumień jest zwykłym DVB-S, więc nie ma tu zbytniej filozofii przy zapisie (nie licząc, że trzeba to robić na komputerze, tylko nieliczne tunery na ALI mają przechwytywanie całego TS, reszta nie ma takiej możliwości).

 

Jakby ktoś miał pomysły, to słucham, ale będę sprawdzać dopiero w przyszłym tygodniu (oddajemy SAT Kurier 7-8/2014 do druku i nie mam czasu).

Odnośnik do komentarza
Udostępnij na innych stronach

Da się zrobić ;) Dla zainteresowanych, ale bez dostępu do 7°E: http://www65.zippyshare.com/v/27373874/file.html

 

W środku trzy pliki:

12632V.ts - zapisany cały TS z 12,633 GHz, pol. V, 5 minut (nazwa z błędem :P )

0x07EE.ts - zapisany tylko PID 2030 (Trójka), 5 minut

trojka_test.ts - efekt eksportu z Wiresharka z całego TS samej Trójki, jak opisałem wyżej, plik powinien mieć 5 minut, a ma 3:15 i dźwięk jest poszarpany, nie do słuchania

 

Może coś źle robię, Wireshark jest bardzo rozbudowany... A może w ogóle czym innym trzeba by popróbować? Jakby ktoś miał pomysł, proszę się dzielić, w poniedziałek to zbadam ;) Fajnie byłoby znaleźć pomysł na to, bo ten przekaz jest być może najlepszym technicznie, jaki jest dla nas osiągalny ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Z wireshark-a chyba niczego więcej już nie wyciągniesz, ponieważ przekazy te normalnie się odtwarzają w mplayer czy ffplay. Problem jest w konfiguracji kodeka, przy którym dźwięk odtwarza się zbyt szybko, ale z normalnym tempem. Będę próbował to jeszcze rozpracować.

 

Tymczasowo jako protezę można zastosować: mplayer -af scaletempo -speed 0.5 -ac faad trojka_test.ts

 

PS. Z odtwarzaniem nagrań z DAB-u jest podobny problem, ale tam sprawa rozbija się o inny rozmiar ramki pakietu (960 zamiast 1024). Jak ktoś ma jakiś pomysł i chce nas naprowadzić na trop, to zapraszam do dyskusji. Ja przeszukałem różne opcje dekodowania w mplayer, ffplay czy vlc, ale na razie nic nie dało pożądanego efektu.

Odnośnik do komentarza
Udostępnij na innych stronach

Faktycznie mplayer sprawia, że jest to słuchalne, aczkolwiek nie brzmi dobrze - dzięki @Qrzysztof :D Zawsze do przodu, co też oznacza, że sposób wyciągnięcia Wiresharkiem ogólnie jest OK (jak rozumiem?), a to z odtwarzaniem jest problem. W weekend nie będę miał dostępu do anteny, ale może jeśli znajdę czas, to też wezmę pliki w obroty i poeksperymentuję z odtwarzaczami i konfiguracją...

Odnośnik do komentarza
Udostępnij na innych stronach

@Mr. Orbita to co złapałeś wygląda na poprawny strumień ts, jednak połowy pakietów IP po prostu brakuje (numery seq transmisji). Część ramek TS nie jest rozwiązywana do pakietów UDP. Problem jest więc z tym, że strumień z tego transpondera jest tylko częścią całości.

Jedyne sensowne wytłumaczenie według mnie - złapałeś więc jeden transponder z dwóch. Trzeba znaleźć i nagrać drugi, zrobić to samo - następnie wrzucić ramki TS z obydwu plików do jednego wora - i powinno wszystko już ładnie grać :)

 

Z doświadczenia przychodzi mi prosty pomysł do głowy - wykonawca takiego "mistrzostwa" po prostu chce mieć kasę, gdyby PR potrzebował jakichkolwiek zmian. W końcu przy czymś takim nikt normalny nie będzie grzebał; a więc skoro nie ma konkurencji to można dyktować ceny :D

Odnośnik do komentarza
Udostępnij na innych stronach

Faktycznie analizując Wiresharkiem widać braki i zwaloną sekwencję, ale znowu z drugiej strony przy aż prawie 50% braków powinienem uzyskać mocno poprzerywany plik, a tymczasem po zastosowaniu pomysłu @Qrzysztofa w sumie gra całość. Dodatkowo przepływność (sam PID dla stacji) jest już na starcie w strumieniu sporo ponad to, czego się spodziewamy, tj. 128 kbit/s AAC, jakieś 75 kbit/s więcej... Sam nie wiem, może walczymy z czymś odwrotnym, tj. w strumieniu jest dodatkowy śmietnik i trzeba umieć to odfiltrować? Patrząc edytorem szesnastkowym do pliku wynikowego widać, że poza audio siedzi w nim RDS, w zasadzie w równych odstępach są więc dane, które może powinny zostać wyczyszczone?

 

Gdyby jednak iść tropem 2 częstotliwości, to jesteśmy w czterech literach, bo znalezienie to jedno (chociaż przeanalizowałem wszystkie serwisy z danymi w górnym paśmie na 7°E namierzone blindscanami na OpenBoxie SX6 oraz TBS6925 i nic więcej nie wpadło mi w oko), a synchronizacja to już chyba niewykonalne bez dedykowanego sprzętu. Strumienie trzebaby nagrać jednocześnie, te same fragmenty i je "złączyć", żeby się faktycznie uzupełniły. Mózg mi paruje uszami jak o tym myślę :P

 

EDIT: Nagrałem paczkę z 39°E - eksport daje takie same rezultaty, stracone pakiety, pogubiona kolejność reszty, odsłuch tak samo jak w Polskim Radiu.

Odnośnik do komentarza
Udostępnij na innych stronach

Może jakimś jednak sposobem kodek sobie radzi z nadrobieniem brakujących części? Słychać dobrze obydwa kanały?

Może Wireshark jednak sobie nie radzi ze złożeniem pakietów (chociaż sam nie widzę dlaczego miałby sobie nie radzić)? Nadmiar danych nie powinien szkodzić, szczególnie takich standardowych

1. Coś się sypie przy nagrywaniu? Firmware/driver lub cokolwiek?

2. Tezę wycofuję, skoro bitrate się zgadza; Ciekawe czy EuroZet ma ten sam sprzęt co PR?

3. Ciekawe co by się stało gdyby ręcznie przenumerować SEQ na kolejne liczby naturalne, ale nie mam ochoty dziś na zabawę ze źródłami. Może jest jednak jakiś błąd we wtyczce.. choć wątpię

Odnośnik do komentarza
Udostępnij na innych stronach

Niestety nie udało mi się rozwiązać tego problemu, choć myślałem, że jestem już bardzo blisko. Na nagraniach znajduje się sporo tzw. śmieci, czyli danych zupełnie nie potrzebnych do normalnego odtwarzania. Sądząc, że one mogą mieć wpływ na zachowanie kodeków czy odtwarzacza (na przykład przeliczenie czasu odtwarzania według rozmiaru pliku), postanowiłem napisać prosty programik w c++ do odfiltrowania treści z plików.

 

Kod może nie jest idealny, ale spełnia swoje zadanie. Nie miałem czasu na jego ulepszanie.

// Program napisany do wyciągania pakietów ADTS z pliku

#include 
#include 
#include 

using namespace std;

int main (int argc, char *argv[]) {
if (argc != 3) { printf("Błędnie podane argumenty"); exit(0); }	

FILE *plik1;
plik1 = fopen(argv[1], "r");

FILE *plik2;
plik2 = fopen(argv[2], "w");

int a,b,d; fpos_t e; char c[5];

fgetpos(plik1,&e);

while ((a = fgetc(plik1)) != EOF) {
	if (a == 0xFF) { b = fgetc(plik1); if ((b&0xF0) == 0xF0) { // znaleziono poprawny nagłówek 0xFFF
		fgets(c,5,plik1);

		std::reverse(&c[0],&c[4]); // zamiana little<>big endian
		d = (*(int*)c&0x0003FFE0)>>5; // rozmiar pakietu wraz z nagłówkiem

		char temp[d];

		fsetpos(plik1,&e);

		fread(temp,sizeof(char),d,plik1);

		fwrite(temp,1,sizeof(temp),plik2);
	}}
	fgetpos(plik1,&e);
}

fclose(plik1);
fclose(plik2);
}

 

Jak ktoś chce, może sobie skompilować. Użycie programu w konsoli na zasadzie: nazwaprogramu plikwejściowy plikwyjściowy

 

Co udało się uzyskać: płynne odtwarzanie w VLC, zmniejszenie rozmiaru pliku trojka.ts z 3,2MB do 2,5MB

Czego się nie udało: uzyskanie normalnej prędkości odtwarzania

Odnośnik do komentarza
Udostępnij na innych stronach

Może za prędkość odpowiada jakiś element nagłówka i modyfikując wszystkie udałoby się "zwolnić" odtwarzanie? Namierzyłem coś takiego, może pomocne: http://wiki.multimedia.cx/index.php?title=ADTS Aczkolwiek byłoby dziwne, aby do odtwarzania trzeba byłoby modyfikować pakiety... Zastanawiam się cały czas też nad tym, czy sposób wyciągania danych jest poprawny - jeśli Wireshark zgłasza błędy, to coś na rzeczy musi być. Do wyciągania używam elementu z menu "telefonia", a przekaz z telefonami nic wspólnego nie ma, może niedostosowanie technologii do tego, co próbujemy zrobić?

 

Nadal jestem zawalony innymi tematami, jak znajdę coś wolnego czasu, to pokombinuję jeszcze...

Odnośnik do komentarza
Udostępnij na innych stronach

To właśnie zrobiłem, z pliku wygrzebałem same pakiety z nagłówkiem ADTS, ale to nie było pomocne. Hex-edytorem zmieniłem próbkowanie z 48kHz na 32kHz (wystarczy zmienić pierwszy), ale z prędkością nadal jest coś nie tak, momentami idzie szybciej lub wolniej, natomiast zmieniła się tonacja.

 

Sądzę, że nic z tym już nie zrobimy i jest to tylko i wyłącznie wina samych ustawień kodeka.

 

Jakby kogoś to interesowało. Przepustowości programów i próbkowanie:

PR1 - 128kbps 48kHz

PR2 - 192kbps 48kHz

PR3 - 128kbps 48kHz

PR4 - 128kbps 48kHz

PRdz - 80kbps 32kHz

 

Poprawka do programu. Przy poprawnym, ale fałszywym nagłówku może wpaść w nieskończoną pętlę (tak miałem z przetwarzaniem strumienia jedynki).

 

// Program napisany do wyciągania pakietów ADTS z pliku

#include 
#include 
#include 

using namespace std;

int main (int argc, char *argv[]) {
if (argc != 3) { printf("Błędnie podane argumenty"); exit(0); }

FILE *plik1;
plik1 = fopen(argv[1], "r");

FILE *plik2;
plik2 = fopen(argv[2], "w");

int a,b,d; fpos_t e; char c[5];

fgetpos(plik1,&e);

while ((a = fgetc(plik1)) != EOF) {
	if (a == 0xFF) { b = fgetc(plik1); if ((b&0xF0) == 0xF0) { // znaleziono poprawny nagłówek 0xFFF
		fread(c,sizeof(char),5,plik1);

		std::reverse(&c[0],&c[4]); // zamiana little<>big endian
		d = (*(int*)c&0x0003FFE0)>>5; // rozmiar pakietu wraz z nagłówkiem

		if (d != 0) {
			char temp[d];

			fsetpos(plik1,&e);

			fread(temp,sizeof(char),d,plik1);

			fwrite(temp,1,sizeof(temp),plik2);
		}
	}}
	fgetpos(plik1,&e);
}

fclose(plik1);
fclose(plik2);
}

 

Odnośnik do komentarza
Udostępnij na innych stronach

Wyprzedzasz moje myśli ;) Ale zgrzyt, jesteśmy już tak blisko, a zarazem tak daleko :/ Polowałem na te dosyły praktycznie odkąd się dowiedziałem dobre 7 lat temu, jak nie więcej, że PR korzysta z górnego pasma na 7°E. Nie odpuszczę - na nadajnikach naziemnych potrafią to odczytać, więc musi się dać. Dzięki za kodzik do czyszczenia strumienia - świetna pomocna sprawa ;)

 

W międzyczasie włączyła mi się nowa zagadka - pod DAB+ teoretycznie potrzebne są także dosyły Radia Rytm i PR24 - osoby feed gdzieś? Czy może zbędny i ciągną po sieci, bo w sumie DAB+ leci z dużych nadajników, które zapewne połączenie mają?

Odnośnik do komentarza
Udostępnij na innych stronach

W międzyczasie włączyła mi się nowa zagadka - pod DAB+ teoretycznie potrzebne są także dosyły Radia Rytm i PR24 - osoby feed gdzieś? Czy może zbędny i ciągną po sieci, bo w sumie DAB+ leci z dużych nadajników, które zapewne połączenie mają?

DAB+ popędzany jest światłowodem.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 miesiące temu...
  • 5 miesięcy temu...

Drobne zmiany - paczkę przesunięto na 12,635 GHz, pol. V i nieco podkręcono SR do 1302 ksps, czyli teraz jest:

12,635 GHz, pol. V, SR: 1302, FEC: 3/4 (DVB-S/QPSK)

 

Mimo podkręcenia SR, na czym zyskali 0,3 Mbit/s zestaw stacji bez zmian, jakość chyba też, a reszta miejsca wypełniona null-pakietami (teraz jakieś 755 kbit/s). Zmieniły się natomiast dane w strumieniu (IP, nazwa - bez dopisku "Spare", tytuł - "Master" zamiast "Spare"), teraz to wygląda tak:

 

PID 2010 = Jedynka IP: 192.168.30.101/230.0.0.10 (nazwa: Jedynka, tytuł: Master_MPEG4_128/48_St)

PID 2020 = Dwójka IP: 192.168.30.102/230.0.0.20 (nazwa: Dwojka, tytuł: Master_MPEG4_128/48_St)

PID 2030 = Trójka IP: 192.168.30.103/230.0.0.30 (nazwa: Trojka, tytuł: Master_MPEG4_128/48_St)

PID 2040 = Czwórka IP: 192.168.30.104/230.0.0.40 (nazwa: Czworka, tytuł: Master_MPEG4_128/48_St)

PID 2050 = PR dla Zagranicy IP: 192.168.30.105/230.0.0.50 (nazwa: Polonia, tytuł: Master MPEG4 2x40/32 Mono)

 

Mając na uwadze dodatkowo to: http://www.ttcomm.pl/pl/2015/01/08/pols ... ego-radia/ być może ta paczka z niższym SR to była jakaś emisja zastępcza/awaryjna ("Spare")? Teraz jej nie widzę obok - tylko tą paczkę "Master".

Odnośnik do komentarza
Udostępnij na innych stronach

  • 3 miesiące temu...

@monter na forum Radio Polska namierzył ciekawy dokument: http://forum.radiopolska.pl/index.php?s ... t&p=323889

Link do samego dokumentu: http://www2.polskieradio.pl/_repository ... /26108.pdf

 

Płyną z niego wnioski iż:

- mamy główny przekaz 5 stacji z SR 1302 ksps (zgadza się - owszem mamy 8) ), oznaczony jako C0001

- mamy też 3 dosyły z wozów SNG do Warszawy - C0002, C0003 i C0004, wszystkie w QPSK z FEC 7/8 i SR 400

- 1 dosył zwrotny z Warszawy dla wozów SNG - C0005, QPSK 3/4 z SR 467

 

Dodatkowa wskazówka: "Zamawiający wymaga aby udostępniona pojemność satelitarna składała się z bezpośrednio ze sobą sąsiadujących nośnych.", czyli polowanie w okolicach 12,635 GHz, pol. V

 

Nie wydaje mi się, żeby kombinowali cokolwiek innego niż DVB-S, aczkolwiek przy C0002-C0005 nie ma wskazania przy FEC użycia RS(204/188). Poza tym jeśli będzie jako strumień IP, to ponieważ ten główny jest nieuchwytny, to za wiele się nie wygrzebie, ale zbadać warto... TBS 6983 (jeśli to będzie zgodne z DVB-S) powinna sobie dać radę, a mając "pewny" SR powinno być dużo łatwiej. Pewnie emisja pojawia się tylko jak są jakieś wejścia na żywo z pleneru w dobrej jakości. Z takich potencjalnych terminów, gdzie może coś być na rzeczy - 12-14 czerwca Orange Warsaw Festival (najprędzej 13 czerwca), 27 czerwca Lato z Radiem z Uniejowa oraz Męskie Granie 2015 z Krakowa.

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 tygodnie później...

Jest coś na rzeczy dziś. U mnie główną paczkę PR wyłapuję na 12,634.333 GHz, pol. V. Tymczasem na 12,631.750 GHz, pol. V przy próbie wstrojenia z SR 400 ksps widzę konstelację QPSK. Odlatując +/- 0,5 MHz znika, więc nie wydaje się to być jakimiś resztkami głównej paczki PR, ale mimo tego nie lockuje się u mnie.

 

124bplw.png

 

Jeśli ktoś chętny i ma sprzęt, to może próbować ;)

 

EDIT: Na 12,632.400 GHz, pol. V też QPSK, ale z SR 467 wychodzi wyraźniej. Też bez lock.

Odnośnik do komentarza
Udostępnij na innych stronach

Jeszcze do niedawna do DSNG wykorzystywany był nieco inny podział segmentu. Być może tymczasowo dla jakichś ważniejszych łączeń DSNG podkręcają SR do starych parametrów (tj. SR 571 kS/s) lub łączą podsegmenty (np. 2x400 kS/s, być może w specyfikacji podane są parametry tylko pojedynczego, "najmniejszego" kanału pod DSNG)?

 

Stare parametry + info o DSNG dla rozgłośni lokalnych (jak ktoś ma chęć to też można ponamierzać ;) ):

http://www.sat-charts.eu/artykul,2800,F ... Radio.html

Odnośnik do komentarza
Udostępnij na innych stronach

  • 2 tygodnie później...

Kolejny dzień polowań :] Dziś będzie dosył z Open'era od 20:00, więc kombinuję. Widzę znowu konstelację QPSK u mnie dziś na 12,631.900 GHz, pol. V, nie jest to jeszcze paczka główna PR, którą już mamy na widelcu.

 

Zrobiłem eksperyment związany z SR: zacząłem od SR 400 ksps. Siedzę w CrazyScan z wyłączonym BlindScanem (na włączonym nie widzi nic), na sztywno częstotliwość, SR, standard na DVB-S, BlindScan odznaczony. Zacząłem zmieniać SR małymi krokami, patrząc na konstelację. Wyszło mi z tego, że SR (przynajmniej w tej chwili) musi być ok. 400, bo już jeśli dam 395 lub 405 ksps - konstelacja rozmazuje się. Najlepszy efekt dostałem na 401 ksps.

 

Sprawdziłem jeszcze DVB-S2, ale nie - konstelacja się rozwala, manewrowanie częstotliwościami nie pomaga. Najlepszy efekt mam zatem w tej chwili na 12,631.900 GHz, pol. V, SR: 401. Antena idealnie wcelowana w 7°E, więc nie wycisnę więcej (patrzę na 180 cm).

 

35d21xw.jpg

 

Czyżby nie typowe DVB-S, czy może jednak sprzęt nie daje rady?

 

Jeśli ktoś akurat jest i ma czas podjechać na 7°E - mamy czas pewnie do 21:00 ;)

Odnośnik do komentarza
Udostępnij na innych stronach

Dołącz do dyskusji

Możesz dodać zawartość już teraz a zarejestrować się później. Jeśli posiadasz już konto, zaloguj się aby dodać zawartość za jego pomocą.

Gość
Dodaj odpowiedź do tematu...

×   Wklejono zawartość z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Odnośnik został automatycznie osadzony.   Przywróć wyświetlanie jako odnośnik

×   Przywrócono poprzednią zawartość.   Wyczyść edytor

×   Nie możesz bezpośrednio wkleić grafiki. Dodaj lub załącz grafiki z adresu URL.

 Udostępnij

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...